3 ms·
Using REST over HTTP certainly gets us a lot for free. But I think we must concede that some APIs somewhere, are not best represented as a small, fixed set of a
by sopooneo 11y ago
Using REST over HTTP certainly gets us a lot for free. But I think we must concede that some APIs somewhere, are not best represented as a small, fixed set of actions on "resources". So then the question becomes, for web APIs, when do the benefits of complying with REST principals get outweighed by the benefits of not?
- dkersten 11y agoI'm not arguing the merits or demerits of REST - just stating that the use case leeoniya outlined can be handled with REST, if you should wish to do so. It would be silly to say that no API ever is not better represented as something else - for example, a bidirectional streaming API (running over, say, WebSockets?) is probably not a great fit for REST, but for request/response-based API's I do find that so far REST is really nice. Some people say that actions or commands aren't nicely represented as resources, but personally I like the idea of POSTing to a command resource in order to tell the server to execute a command (and GET could be used to retrieve all outstanding commands, PUT to replace one, DELETE to cancel etc). Again, not requiring a 1:1 match between resource and database makes this possible. However, even within the world of REST, people have different approaches, so at the end of the day, to each his own. Use what you feel is simplest and makes most sense.