REST on SWiK

SitePen Blog " RESTful JSON + Dojo Data

Fri, 29 Aug 2008 22:00:06 -0700

SitePen Blog " RESTful JSON + Dojo Data

Fri, 29 Aug 2008 21:58:57 -0700

Using the built-in REST API — sproutcore — GitHub

Fri, 29 Aug 2008 19:58:13 -0700

RESTful JSON

Fri, 29 Aug 2008 14:01:05 -0700

Joe Gregorio | BitWorking | RESTful JSON

Fri, 29 Aug 2008 13:01:11 -0700

HTTP/1.1: Method Definitions

Fri, 29 Aug 2008 12:58:50 -0700

JSON " Blog Archives " Standardizing RESTful JSON

Fri, 29 Aug 2008 12:01:09 -0700

RESTful Web Services and Comet

Fri, 29 Aug 2008 10:51:54 -0700

Joe Gregorio | BitWorking | RESTful JSON

Fri, 29 Aug 2008 07:01:38 -0700

am loving Beyond REST and the PIMP protocol

Fri, 29 Aug 2008 03:55:37 -0700

I really enjoyed reading Joshua Schachter's post beyond rest today - and particularly the comments. The basic idea is how to get a kinda publish/subscribe system to work on the web for processing real time updates to things like social sites at internet scale without introducing some really complex new protocol; but reusing the lovely RESTful web endpoints.

I posted a comment in the thread but figured it was quite big so figured I'd post it here too :)

I'm really liking the PIMP protocol and like Sam's strawman of using caching headers to implement it...

My suggestion is to think of this instead as another form of caching. All we really want is a header that tells the server that we are interested when a particular resource has been updated and how to tell us. The server can then either understand that header and acknowledge in the response that it will notify me. Here is my strawman:Request:
...
X-Cache-Callback:http://www.javarants.com/notify/joshua.schachter.org/atom.xml;SECRET
Response:
...
X-Cache-Callback: OK

Then if that resource is updated the service is expected to either HEAD the callback as a notification or POST the new contents of the resource, servers choice. You could later add semantics for merely updating the resource vs replacing it wholesale. I would also think about adding the ability for the server to specify a timeout after which you are free to poll again if you haven't heard anything on the assumption that sometimes the service may lose the state associated with your subscription.

Am thinking rather than returning OK the server returns the amount of time before the client has to re-issue the subscription to keep it alive. So the server can decide the maximum subscription time. Good PIMP servers (PIMPS :) might wanna make this quite long to reduce the polling overhead.

I also love the simplicity of the HEAD or POST to differentiate a notification of change to a notification-with-the-data.

I've long wanted a 'SUBSCRIBE' verb in HTTP for doing this kinda thing; but I think your cache-header approach is cleaner - as folks can either keep polling and/or subscribe for the update notification.

The nice thing too is that it allows easy migration to PIMP without introducing any overhead or new traffic; that clients continue to poll as normal - but they advertise themselves as being PIMP aware. Then eventually when one day the server becomes PIMP aware the clients receive their notifications (and then hopefully they scale back their polling :) - otherwise they can stick to polling.

Also webmasters can monitor their traffic looking for PIMP headers to know when it'll make sense to upgrade to PIMP. Not everyone is gonna need PIMP and it'll be a no brainer from looking at your logs to determine both when you've sufficient mass of PIMP enabled pollers along with knowing what the reduction in polling traffic upgrading to PIMP would save you.

I'm with Sam in the thinking of this as another form of caching. In implementing PIMP some folks might be able to create update notifications internally in their system when resources change to push out change messages into some kinda queue for posting to the callback URL. This would involve significant work for many sites though.

However it'll surely be pretty trivial to just install a PIMP-enabled caching web proxy inside your data centre in front of your servers - that does the usual cache thing, but also detects these extra PIMP cache headers and does a background poll of resources (respecting your existing cache & time to live headers) to detect changes both to update the cluster of front web caches (so non-PIMP pollers get more real time data) but also to drive the pushing of updates out to PIMP subscribers.

i.e. I can see this as a pretty easy upgrade to most web sites - folks just update their front end web proxies to a PIMP-enabled version and hey presto you can now support PIMP consumers. Am sure the web proxies could include an XMPP firehose too pretty easily for heavy hitters.

It should be pretty easy to hack the web proxies to do this I'd have thought? Even the problem thats been noted earlier in this thread - of trying to push updates to a URL endpoint might be slow, unresponsive or unavailable - the web proxies have to deal with already right in case a *local* server is borked.

Anyway - its a very interesting blog post and particularly the comments. Interesting stuff.

Joe Gregorio | BitWorking | RESTful JSON

Fri, 29 Aug 2008 00:59:11 -0700

restful-json |

Fri, 29 Aug 2008 00:59:11 -0700

RESTful JSON: Bringing REST and RPC Closer Together

Fri, 29 Aug 2008 00:59:11 -0700

Joe Gregorio | BitWorking | JEP

Fri, 29 Aug 2008 00:59:10 -0700

RESTful Web Services and Comet

Fri, 29 Aug 2008 00:51:47 -0700

RESTful Web Services and Comet

Getting Data | The REST Dialogues | What Not How | http://duncan-cragg.org/blog/

Thu, 28 Aug 2008 20:57:48 -0700

Architectural Styles and the Design of Network-based Software Architectures

Thu, 28 Aug 2008 20:57:48 -0700

Representational State Transfer - Wikipedia, the free encyclopedia

Thu, 28 Aug 2008 20:57:48 -0700

Joe Gregorio | BitWorking | RESTful JSON

Thu, 28 Aug 2008 19:59:46 -0700

RFC 4287 - The Atom Syndication Format

Thu, 28 Aug 2008 19:58:26 -0700

Joe Gregorio | BitWorking | RESTful JSON

Thu, 28 Aug 2008 18:12:07 -0700

ongoing · Tab Sweep — Technology

Thu, 28 Aug 2008 18:12:07 -0700

Joe Gregorio | BitWorking | RESTful JSON

Thu, 28 Aug 2008 18:12:07 -0700

what would RESTful JSON look like?

Standardizing RESTful JSON

Thu, 28 Aug 2008 18:12:07 -0700

SnapLogic Open Source Data Integration Framework for SaaS Integration

Thu, 28 Aug 2008 18:09:50 -0700

[from bushwald] The continuum of access styles in the emerging Microsoft cloud " Jon Udell

Thu, 28 Aug 2008 18:09:46 -0700

Jersey 0.9 is out -- 1.0 is Next!

Thu, 28 Aug 2008 18:08:13 -0700

Almost final, Jersey 0.9 is Out! This is the implementation that goes with the 0.9 version of the spec (Docs, Spec); this release also has Maven packages for its components at http://download.java.net/maven/2/com/sun/jersey/.

JAX-RS (aka JSR 311) has done a very good job on transparency and I think that has reflected in the quality and adoption. See Jersey for more stories.

Silverlight Web Services Team

Thu, 28 Aug 2008 18:05:23 -0700

Clemens Vasters - Teaching Indigo to do REST/POX, Part 2

Thu, 28 Aug 2008 18:05:23 -0700

In the first part of this series, I gave you a little introduction to REST/POX in contrast to SOAP and also explained some of the differences in how incoming requests are dispatched. Now I’ll start digging into how we can teach Indigo a RESTish dispatch mechanism that dispatches based on the HTTP method and by matching on the URI against a suffix pattern.

Stefan Tilkov: Clemens Vasters on REST/POX

Thu, 28 Aug 2008 18:05:23 -0700

Clemens Vasters essentially writes about the same topic as Sanjiva; the same comments of mine apply. Attempts to abstract away the concept of URIs as the price of consolidating REST and SOAP are fundamentally ill-fated … POX is not REST.