Polling

The client keeps polling the server to get 10 the status of the response.

Pros

• Being really RESTful means cacheable and scaleable.

Cons

• Not the best responsiveness if you do not want to poll your server too much.

Persistent connection

The server does 9 not close its HTTP connection with the client 8 until the response is complete. The server 7 can send intermediate status through this 6 connection using HTTP multiparts.

Comet is the 5 most famous framework to implement this 4 behaviour.

Pros

• Best responsiveness, almost real-time notifications from the server.

Cons

• Connection limit is limited on a web server, keeping a connection open for too long might, at best load your server, at worst open the server to Denial of Service attacks.

Client as a server

Make the server post status updates 3 and the response to the client as if it 2 were another RESTful application.

Pros

• Best of every worlds, no resources are wasted waiting for the response, either on the server or on the client side.

Cons

• You need a full HTTP server and web application stack on the client
• Firewalls and routers with their default "no incoming connections at all" will get in the way.

Feel free 1 to edit to add your thoughts or a new method!

I guess it depends on a few factors

• How accurate the feedback can be (1 percent, 5 percent, 50 percent)
  Accurate feedback makes it worth pursuing some kind of progress bar and comet style push. If you can only say "Busy... hold on... almost there... done" then a simple ajax "are we there yet" poll is certainly easier to code.
• How timely the Done message has to be seen by the client
• How long each task takes (1 second, 10 seconds, 10 minutes)
  1 second makes it a bit moot. 10 seconds makes it worth it. 10 minutes means you're better off suggesting the user goes for a coffee break :-)
• How many concurrent requests there will be
  Unless you've got a "special" server, live push style systems tend to eat connections and you'll be maxed out pretty quickly. Having to throw more webservers in for a fancy progress bar might hurt the budget.

I've 15 got some sample code on 871184 that shows a hand 14 rolled "forever frame" which seems to work 13 out well. The project I developed that for 12 isn't hammered all that hard though, the 11 operations take a few seconds and we can 10 give pretty accurate percent. The code uses 9 asp.net and jquery, but the general techniques 8 will work with any server and javascript 7 framework.

edit As John points out, status reporting 6 probably isn't the job of the RESTful service. But 5 there's nothing that says you can't open 4 an iframe on the client that hooks to a 3 page on the server that polls the service. Theory 2 says the server and the service will at 1 least be closer to one another :-)

Look into Comet. You make a single request to 10 the server and the server blocks and holds 9 the connection open until an update in status 8 occurs. Once that happens the response is 7 sent and committed. The browser receives 6 this response, handles it and immediately 5 re-requests the same URL. The effect is 4 that of events being pushed to the browser. There 3 are pros and cons and it might not be appropriate 2 for all use cases but would provide the 1 most timely status updates.

My opinion is to stick with the polling 2 solution, but you might be interested in 1 this Wikipedia article on HTTP Push technologies.

REST depends on HTTP, which is a request/response 6 protocol. I don't think you're going to 5 get a pure HTTP server calling the client 4 back with status.

Besides, status reporting 3 isn't the job of the service. It's up to 2 the client to decide when, or if, it wants 1 status reported.

One approach I have used is:

1. When the job is posted to the server, the server responds back a pubnub-channel id (one could alternatively use Google's PUB-SUB kind of service).
2. The client on browser subscribes to that channel and starts listening for messages.
3. The worker/task server publishes status on that pubnub channel to update the progress.
4. On receiving messages on the subscribed pubnub-channel, the client updates the web UI.

0

You could also use self-refreshing iframe, but 8 AJAX call is much better. I don't think 7 there is any other way.

PS: If you would 6 open a socket from client, that wouldn't 5 change much - PHP browser would show the 4 page as still "loading", which is not very 3 user-friendly. (assuming you would push 2 or flush buffer to have other things displayed 1 before)