Alan Dix Snip!t: ongoing by Tim Bray

see all channels for Alan Dix

Snip summary	To summarize: For any and all PUT/POST/DELETE operations... In progress” and a new “Status” resource, which co... progress indicator, a target_uri for whatever’s being ... to identify the operation, and, when progress reaches 10... We also tho ongoing by Tim Bray · Slow REST http://www.tbray.org/ongoing/When/200x/2009/07/02/Slow-REST

Categories

/Channels/techie/web development

[ go to category ]

For Snip	loading snip actions ...
For Page	loading url actions ...

To summarize: For any and all PUT/POST/DELETE operations, we return “202 In progress” and a new “Status” resource, which contains a 0-to-100 progress indicator, a target_uri for whatever’s being operated on, an op to identify the operation, and, when progress reaches 100, status and message fields to tell how the operation came out. The idea is that this is designed to give a hook that implementors can make cheap to poll.

We also thought about a Comet style implementation where we keep the HTTP channel open, and that can be made clean but support for it in popular libraries is less than ubiquitous. My personal favorite idea was to use “Web hooks”, i.e. the client sends a URI along with the request and the server POSTs back to it when the operation is complete. But every time I started talking about it I ran into a brick wall because it probably doesn’t work for a client behind a firewall, which is where most of them will be. Sigh.

HTML	<p>To summarize: For any and all PUT/POST/DELETE operations, we return “202 In progress” and a new “Status” resource, which contains a 0-to-100 <code>progress</code> indicator, a <code>target_uri</code> for whatever’s being operated on, an <code>op</code> to identify the operation, and, when <code>progress</code> reaches 100, <code>status</code> and <code>message</code> fields to tell how the operation came out. The idea is that this is designed to give a hook that implementors can make cheap to poll.</p> <p>We also thought about a Comet style implementation where we keep the HTTP channel open, and that can be made clean but support for it in popular libraries is less than ubiquitous. My personal favorite idea was to use “Web hooks”, i.e. the client sends a URI along with the request and the server POSTs back to it when the operation is complete. But every time I started talking about it I ran into a brick wall because it probably doesn’t work for a client behind a firewall, which is where most of them will be. Sigh.</p>

HTML

<p>To summarize: For any and all PUT/POST/DELETE operations, we return “202 In progress” and a new “Status” resource, which contains a 0-to-100 <code>progress</code> indicator, a <code>target_uri</code> for whatever’s being operated on, an <code>op</code> to identify the operation, and, when <code>progress</code> reaches 100, <code>status</code> and <code>message</code> fields to tell how the operation came out. The idea is that this is designed to give a hook that implementors can make cheap to poll.</p> <p>We also thought about a Comet style implementation where we keep the HTTP channel open, and that can be made clean but support for it in popular libraries is less than ubiquitous. My personal favorite idea was to use “Web hooks”, i.e. the client sends a URI along with the request and the server POSTs back to it when the operation is complete. But every time I started talking about it I ran into a brick wall because it probably doesn’t work for a client behind a firewall, which is where most of them will be. Sigh.</p>

Snip!t from collection of Alan Dix

Search Alan Dix Snips

Channels - Alan Dix