Reputation: 35235
I have a messenger app that makes GET /conversations
requests to populate a list of the conversations of the user.
The next step is to make it "listen" for updates so that it marks conversations that have been updated and add conversations that have been created.
Should I use the same /conversations
resource to get the updates or should I rather have a separate resource for that? Perhaps, something like /conversationUpdates
.
Upvotes: 0
Views: 1848
Reputation: 22553
It depends on whether you want to follow RESTful conventions. Many client side libraries such as backbone and extjs have fairly deep support for declaring a resource with a URI and then using the different HTTP methods (GET, POST, DELETE, etc.) against it. This might sometimes lessen the work clients need to do and folks will be grateful.
Following the convention will also make your api less surprising. There are undoubtedly other conventions for API's and not every domain space is well modeled with REST.
Rereading your post, I see you want to have an api that that just gets new posts. What constitutes new? New since the last time the client called the end point? In such instances an api might accept a parameter like the last identifier that had been received (if you are using something like a auto increment field, or a mongodb id). In that case you would just use the /conversations
endpoint, with an extra parameter.
Upvotes: 1
Reputation: 921
Firstly, I'd stick here with the GET method, since this is exactly the point: getting data.
As for the resource name, I'd go with the same, specifying it further in the query, something like /conversations?state=new
. My point here is that the resource itself is still the same but you only want a subset of it.
However, if you plan on updating other things than conversations, you can use /updates/conversations
since in this case, an update can be considered as a resource, itself composed of, among other things, conversations.
Upvotes: 0