LO-REST pattern for exyus
while handling some mundane tasks this AM, i think i hit upon a reasonable pattern for handling LO-REST within exyus.
since LO-REST only handles GET and POST (more specifically, does not handle PUT and DELETE), the general thinking is any updates are sent from the client to the server using a POST w/ additional information for indicate the 'underlying' method (PUT, DELETE, etc.). a good example is a browser client that has scripting turned off and uses just an HTML FORM (since it only handles GET and POST):
<form method="POST" action="http://example.org/documents/post-only/"> <input type="hidden" name="method" value="delete" /> <input type="hidden" name="resource-url" value="/documents/" /> <input type="text" name="id" value="13" /> <input type="submit" name="Delete" /> </form>
note the method
and resource-url
elements in the FORM. that's the real HTTP Method to execute and resource the user wants to work with. also note the action
attribute on the FORM. it points, not to the "documents" resource, but to another sub-resource - "documents/post-only/." this is a resource that is designed to handle the LO-REST cases only.
the "post-only" resource accepts the application/x-www-urlencoded
document, inspects the method
element, and then composes and executes the indicated HTTP Method on the indicated resource. so it's essentially a gateway. this preserves caching and other fun stuff (since the underlying resource will be updated in the expected manner) without over-complicating the underlying resource's POST method with lots of other whacky stuff.
there are some things to work out here (it it important to limit the method
and resource
in a way that will prevent attacks, races, etc.?), but i think it's a clean and simple solution.
i'm getting behind, but hope to get an example of this working this week.