Comments on: Fomenting unREST : Is RESTfulness a semantics game ? Why does REST require statelessness ?

By: Mike Burrows

Mike Burrows — Tue, 09 Jun 2009 16:27:23 +0000

Of course there is state in the server – it would be a very boring application otherwise! Its the communication that needs to be stateless, a principle that’s violated by the use of cookies (and by some uses of headers also).

Pragmatically though, I think security has to be an exception to this, but hopefully one that’s made as transparent as possible to the application protocol.

By: What is statelessness in REST ? | /var/log/mind

What is statelessness in REST ? | /var/log/mind — Tue, 07 Apr 2009 16:43:33 +0000

[...] my post Fomenting unREST : Is RESTfulness a semantics game ? Why does REST require statelessness ?, I had commented on some of my thoughts on dealing with some of the constraints prescribed by REST [...]

By: Surya Suravarapu

Surya Suravarapu — Sat, 04 Apr 2009 02:04:13 +0000

REST is stateless, meaning there is no session state tied to a particular client stored on the server. Session id / authorization token is something that you may not want to pass on as a part of the URI. I think the authentication part belongs to the header area.

Standard authentication mechanisms like Http Auth, OAuth can help achieve this. Another way of achieving this is by using cookies. The tricky thing with cookie is to make sure that the server validate the cookie with out session state. I read this piece recently on using digest with cookies on the REST-discuss group: http://tech.groups.yahoo.com/group/rest-discuss/message/10909

By: Dhananjay Nene

Dhananjay Nene — Fri, 03 Apr 2009 21:53:28 +0000

If you are providing a REST api then session id is not required.

Agreed in principle. But the way I read REST, a purist approach would completely abhor session id, since that id typically is linked to some state on the server.

There are many ways how we can implement a pure REST api for this particular case study. Eg. implementing REST version of oAuth to minimize sending critical info all the time and using smaller access tokens.

Interesting. Would an oAuth access token be considered a id or a resource ? Not sure.

By: Sushrut Bidwai

Sushrut Bidwai — Fri, 03 Apr 2009 20:00:29 +0000

First of all I am not sure if seesion id is required. If you are providing a REST api then session id is not required. There are many ways how we can implement a pure REST api for this particular case study. Eg. implementing REST version of oAuth to minimize sending critical info all the time and using smaller access tokens. But that is not the point.
Point you have raised is correct, sometimes being creator of a technology or architecture style (in this case) we tend to be too rigid about rules and regulation. the best we not so REST api providers can do is call it REST99 (99.9% pure REST) and leave it there.

By: Mike Davison

Mike Davison — Fri, 03 Apr 2009 17:49:14 +0000

Great article that delves into the practical side of the HATEOS debate. Well done.

By: Software / IT Terms in early stages of abuse or ripe for Abuse | /var/log/mind

Tue, 27 Jan 2009 21:05:54 +0000

[...] There is another issue as well with using REST as the moniker to describe HTTP based APIs. Roy Fielding eloquently points out that REST is so different from RPC. Yet in a logical sense, many requirements for HTTP APIs are very RPC like. It is possible to represent such an API using REST semantics (instead of user/delete/123 call it userdeletion/create/123 .. a name mangling trick). Moreover REST requires statelessness, a requirement that not all applications necessarily comply with. I am not suggesting they should, just that should they choose to not be completely stateless it would be difficult to term their APIs REST. These were both issues I had referred to in my earlier post Fomenting unREST : Is RESTfulness a semantics game ? Why does REST require statelessness ?. [...]