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 wou

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.