I'm specifically interested in how users perform authorized / authenticated operations on a web API.
Are authentication cookies compatible with the REST philosophy, and why?
|show 1 more comment|
An ideal ReSTful service allows clients (which may not be in-browser) to perform any needed task in one request; because the full state needed to do that is held by the client, not the server. Since the client has full control of the state, it can create the state on its own (if that is legitimate), and only talk to the API to "get 'er done".
Requiring cookies can make that difficult. For clients besides browsers, managing cookies is a pretty big inconvenience compared to query params, plain request headers or the request body. On the other hand, In browser, using cookies can make lots of things much simpler.
So an API might first look in the
Another example might be a complex request that normally requires lots of parameters set. A non interactive client would have no trouble jamming all of that data into one request, but a HTML form based interface might prefer to break the request into several pages (something like a set of 'wizard' pages) so that users aren't presented with options that are not applicable based on previous selections. All of the intermediate pages could store the values in client side cookies, so that only the very last page, where the user actually submits the request, has any server side effect at all. The API could look for the needed attributes in the request body, and fall back to looking at cookies if the needed parameters weren't there.
Yes and No - Depends how you use it.
Cookies if used to maintain client state at the client, for the client, of the client and by the client then they are restful.
If you are storing server state into the cookie then you are basically just shifting the load to the client - which isn't restful.
So what are some examples?
Restfulness comes from statelessness - of the server. Clients can maintain application state and send it to the server to say where they are so that the server can decide where to go from there. Basically sessions/states need historical data and are dependent on past requests so to speak, restful applications ideally aren't (It's not viable to have a 100% pure restful application if you are going to have a login screen :)
REST requires that any session information be stored on the client side, but when it comes to authentication, some information has to stay on the server side for security reasons.
From one of my blog posts, there is a general agreement that authentication data is considered out of scope regarding REST. Hence, it is ok for servers to keep some of this session data on their side.