3 ms·
When your API is RESTful you have a lot less explaining to do in your documentation. It totally makes sense for services to conform to the same pattern.
by gaika 18y ago
When your API is RESTful you have a lot less explaining to do in your documentation. It totally makes sense for services to conform to the same pattern.
- tlrobinson 18y agoAssuming the service maps cleanly to the HTTP verbs, which if it does he says by all means use a RESTful interface, but if not, don't be afraid to make it non-RESTful.
- gaika 18y agoDo you have an example of an online service that doesn't fit into RESTful model?
- paul 18y agoNearly all of them? Run your packet sniffer on Gmail for example -- I guarantee that send isn't implemented with a PUT to noun url!
- gunderson 18y agoAnd your point?
- paul 18y agoHe 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".
- gaika 18y agoSorry, but I asked about a service that doesn't FIT the RESTful model.
- paul 18y agoWell, 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.
- gaika 18y agoRight, 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.
- paul 18y agoI 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.
- gaika 18y agoWhat's wrong with creating a subscription object and letting people manipulate it the usual REST way via /subscription/<id>? That way you can list your subscriptions, modify, delete in a very consistent way, without a need for "POST /actions/modify_subscription" and such.
- bct 18y agoREST 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.
- gunderson 18y agoThis 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.
- gaika 18y agoYou 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.
- richcollins 18y agoYou have more explaining to do. Most api users have no idea WTF DELETE and PUT are.