CODEWITHSUNDEEP
ruby-on-railsrest
John Lockwood
John Lockwood

Reputation: 3875

The limits of RESTful architecture

I'm wondering to what extent people keep their applications RESTful. It seems to me that things break down extremely easily, at which point I have to do what a senior programmer once told me when I was new in my career and getting all philoso-architectural on him: "Just write the damned code."

Specific example, I'm implementing custom authentication in Rails app, and I have a standard "Password Reminder" form. What we're going to do at the end of the process from a REST point of view would be a PUT on a User object, since we're updating the user object. But even ignoring that there are multiple ways you might want to update a user (c.f How to do REST-ful updates?), we don't know what user we're updating at the outset, and by the end we're going to send out an email confirmation and follow a link back using a user identifier + secure key. So now the thing that finally triggers the update on the user is a simple link (oh the horror!) -- or else I have to annoy my user with another button for the sake of being RESTful.

This is just one of the examples that prompted my question, but it seems to me that in any non-trivial app there's bound to be dozens of such cases.

So do folks pretty much use RESTful archietectures as a general guideline that artful programmers ignore as needed? The impression I get from the literature is quite different from that -- hence the question as to how you've dealt with the exceptions. Thanks.

(Actually it occurs to me that the final result in this case would be another form with the new password / confirmation, the target of which could be the PUT, but my general sense that this is sometimes unwieldy is still with me. Maybe that's my own slowness -- won't be the first time).

Upvotes: 2

Views: 208

Answers (2)

fumanchu
fumanchu

Reputation: 14559

From http://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_4:

REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

If you need instead an architectural style that emphasizes obfuscation of actors and resources, point-to-point one-off interaction, and wholehearted embracing and exposure of legacy systems (like HTML email), then no, you don't need to be RESTful. Find (or invent) an architectural style that fits your criteria. There's nothing magic about REST; it's a set of constraints that happens to work for many problem domains because it was designed for, and meets, their needs. If you have different needs, applying the same constraints would be counterproductive and foolish.

Upvotes: 0

theon
theon

Reputation: 14390

Where I work we have decided to try to be as RESTful as we can, but we are also going to be pragmatic and when something doesn't fit well with REST guidelines (and everyone involved agrees this is the case), then will be willing to diverge. Saying that, I think you can make most use cases somewhat RESTful.

How about something like this if you do not know the user's ID. A collection of change password tokens with the id as the email address:

GET /changepasswordtoken/{userEmail}

Or if the client of the API knows the User ID this would be nicer maybe:

GET /user/{userId}/changepasswordtoken

You are asking to GET the change password token for the user. If this is a public facing API, then obviously you won't return this in the response payload, but the payload could return a message saying "Change Password Sent to Email" or something.

Then to update the password PUT or PATCH the user with the change password token as a querystring parameter.

PUT /user/{userId}?changepasswordtoken=xyz

{
     "password": "new password"
}

Upvotes: 1

Related Questions