

Ask HN: Designing a REST API - dwilkie

I am in the middle of building a REST api using Rails. Basically a client app can post to the api with a message and an author. The service then figures out what to reply and who to reply to in a background process.<p>My question should I design it so that the api posts back to the client's callback url when the reply message has been calculated (similar to Paypal IPN) or should the I design it so that the client must poll the server to see when the reply has been generated?<p>e.g.<p>Polling solution
Client app:
POST myapi.com/messages<p>then poll
GET myapi.com/messages/2324<p>Callback URL solution<p>Client app:
POST myapi.com/messages<p>server:
POST clientapp/messages<p>My initial thoughts are that a callback url is better because less requests have to be made from the client to the server. And the client app will also be simpler and more responsive since there is no polling required. But this doesn't seem very RESTful? Should I care? Are there any advantages of having polling solution that I'm overlooking?
======
dickeytk
pollback is definitely not RESTful, but that doesn't mean it's bad. Both
methods can work for different scenarios.

Also, you could look into long polling using redis or something.

------
rhizome
Can you think of any APIs that use the pollback method?

~~~
dwilkie
Paypal use a callback method for their IPNs

~~~
rhizome
I meant the mentioned method by which the client polls back to the API for
request/transaction status.

