3 ms·

a simple example is a one-click payment + order action A user action doesn't have to correspond to a single API call. Your users single click could translate t

a simple example is a one-click payment + order action A user action doesn't have to correspond to a single API call. Your users single click could translate to multiple API calls. Additionally, as others have already mentioned, a conceptual resource does not have to equal a database entry. In an application (front and back end) there are probably three data models: whats in the database, the "resources" transferred over the API, and what the client has locally (in memory or disk or both) and these three don't necessarily have a 1:1 mapping. For example, in an application I'm working on, the client stores a transformed denormalised version of the resources that allows easy filtering/searching/sorting in the UI, the API resources are very regular semantic "things" and the database stores them in a way that is easy to index and perform access control checks on.

sopooneo 12y 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 12y ago
  I'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.

sopooneo 12y 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 12y ago
I'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.