He asked for an example of a web service that doesn't follow the RESTful model. I replied to his request. My point is that almost no web service is truly "RESTful".
Well, I guess it depends how you define "FIT". It's possible to shoehorn just about any service into just about any model, but that doesn't make it a good idea. For example, sending email by doing a PUT to some newly created URL is silly. There's a reason that the english language has more than 5 verbs.
Right, closer analogy would be object oriented programming, where some methods are standard (constructor->post, destructor->delete, copy->get, assignment->put) and some are totally type specific. The point of REST is that these type specific methods do not have to pollute your core / transport and can happily reside in your client libraries.
Sending email is best mapped to POST (create), not PUT (update), and the URL doesn't change for POST.
I think perhaps we're talking about a different aspect of REST.
What I find annoying is people objecting to "POST /actions/subscribe" (with the params in the post body) because it's "non-RESTful" -- the url is a verb and REST demands a noun.
REST doesn't demand a noun. If they all have the same code backing them, there's no functional difference between:
POST /actions/subscribe
and
POST /subscriptions
and
POST /abcdef1234567890
The shape of a URL has nothing to do with REST. However, if a lot of your URLs contain verbs it suggests that you aren't doing REST. It's a design odor.
This is a fun question. I don't, but I'm curious what you think are the most persuasive examples of services that don't fit.
One that comes to mind is a service with semantics that require a preview step. Sure you can use create/read/update via the REST verbs, but I think a lot of the confusion on this issue comes from wanting to embed the concept of events, so a read may be for the purpose of previewing an item, but it feels more natural to fire a "confirm" event than to do a post with a field called state=cofirmed.
At least that's my personal opinion. I agree that any service can be mapped given sufficient creativity, but it often seems like extra work in the context I described.
You can think of RESTful approach as an extreme case of object oriented programming when your methods are limited to CRUD.
Obviously there are cases when there's more than one way to change the state of the object that are only relevant to that object type. In the web world usually the full object state is already on the client so it is not a big deal. You can have your special methods in the client side library and still expose only CRUD methods in the service API.
