Popular posts

Read more about the technique @JanVladimirMostert mentioned when you google for 'webhooks'. It's quite often used. If the user cannot register (say from a smart phone or desktop) http messaging would be a good option, assuming an always-on client or long term web client search for websockets (as @peek4y mentioned).

Of course you can always use something that returns a transaction id and poll for the status on that later.

It's entirely up to your use case. Is the API meant to be consumed by webservers or by something else? that would be my first question.

Thanks! That was useful.

We implemented something very simple when we had to do public async type API calls, user does transaction, gets a response back saying we'll ping him later since we don't have the data yet.

Once we have the data, we do a POST request to the client with just a transaction ID, we expect the client to respond with an OK if they received our POST request, once we receive the OK from the client, we stop trying to publish to the client (if we don't get the OK after multiple attempts over two days, we send an automated email saying their endpoint is down and that we're trying to notify them that transaction id xyz is ready for querying)

Now once the client sent us the OK, we have the data available and the client simply needs to do a query request using the transaction id they've received.

This is a public API that we are implementing.