

REST is not perfect for everything - ownedthx
http://www.ownedthx.com/blog/?p=8

======
stcredzero
It's a good sign that REST is not perfect for everything. Trying to be
everything to everyone is a _trap_ that framework and API designers fall into.
You should actually aim for making most people mostly happy, but leave some
people rather bummed out.

(Google tech Talk on Designing an API.)
<http://video.google.com/videoplay?docid=-3733345136856180693>

If your plans make everyone happy, you're probably trying to do too much.

~~~
lrm242
Unfortunately, you find none to often folks using REST to solve a wide range
of problems that it isn't suited for. The point of this post is to point that
fact out: just because REST exists doesn't mean you have to use it. Believe it
or not, this is actually a surprise to a lot of people, especially those
trying to be in some way 'Web 2.0'.

Quick EDIT: I've actually seen people try to design fundamentally stateful
APIs using REST. These people admit they are stateful, and that they must be
stateful, yet they continue to use REST because it's what various web
companies use and promote (for totally different problems).

------
DougWebb
Stateful and REST can get along pretty well, depending on what's stateful.
Your resources should be stateful; they don't disappear when the request is
completed. Your client-side application should be stateful too; among other
things, it keeps track of the user's linking from one representation to the
next. The only thing that's stateless is the request... any given request
should not depend on sending some other request first, except for the case
where the first request changes the state of a resource, and the second
request retrieves a representation of that resource.

I just designed a RESTful API, and it's built upon a very stateful backend.
From the client's perspective, the only hint of statefulness is that the API
sends Set-Cookie response headers, and expects to get Cookie request headers
back. When they're sent, performance is much better. But to keep the requests
stateless, the Cookie headers are optional. If they're not sent, the URL
provides enough info to recreate the backend state. This is slower, but
functionally equivalent, and I think it's an approach that qualifies as being
fully and correctly RESTful, while still being essentially stateful
internally.

------
vstanford
Well said. I can already envision the "technical leaders" who are passengers
on the web 2.0 bandwagon reassuring themselves that there architecture
decision was the correct one based off of the first 3 articles that popped up
on their Google search. It's sad but true the blissful ignorance of some folks
making strategic development decisions...I see it all the time in my company.

------
oh_ryan
Why do client-directed messages work poorly with REST?

If there are any other helpful links on REST implementation, particularly
working with legacy systems who are not already RESTful, that would be helpful
for my start-up.

Otherwise, i'll just keep googling. thanks!

~~~
ownedthx
The reason is simple: REST forbids a server being aware of client state. So
practically, this means sessions are off limits; cookies for managing sessions
are meaningless in such a world.

To send an event to a client, though, means the server must have some sort of
awareness of the client. Otherwise, it wouldn't know to send the client a
message in the first place.

So, can you have events in conjunction with REST? Sure. Just realize once you
do that, your application isn't 100% RESTful. It's RESTful and... RESTless I
guess :)

------
ZeroGravitas
I feel more effort was put into creating a sensational headline than the rest
of the text. There's no meat here, it tells you nothing about REST or proposed
alternatives.

