This might make more sense with a concrete example - see http://github.com/asplake/path-to/blob/master/examples/delicious.rb for metadata-driven API access to Delicious, brief writeup at http://positiveincline.com/?p=254.
Mike On May 7, 2:05 pm, "Mike Burrows (asplake)" <m...@asplake.co.uk> wrote: > Hi all, please read on if you're interested in REST and web APIs. > > I have posted roadmaps for described_routes and path-to (both > available as rubygems or at asplake's github) > athttp://positiveincline.com/?p=213. > The excerpt below is their manifesto. I would be very grateful for > comments, whether here or on the site. > > Thanks! > Mike > m...@asplake.co.ukhttp://positiveincline.comhttp://twitter.com/asplake > > Clients of RESTful web applications typically use prior knowledge of > the target application’s structure to generate URIs. This approach is > often very convenient, but much of this URI generation is hard-coded, > and (worse) spread across client code. This introduces a high degree > of coupling and makes clients unnecessarily vulnerable to server-side > change. > > Steps to improve this situation: > > 1. In clients, centralise the generation of URIs and make the > process driven by configuration data > 2. Have servers publish the required configuration data - i.e. > application metadata - in a readily understood format > > path-to provides the means for client applications to model web > applications in terms of logical structure and URI mappings, and to > interact with them through dynamically-generated application-specific > APIs. described_routes supports an application metadata structure > (published in JSON, YAML and XML formats) that can be consumed by path- > to, and (helpfully) generates it automatically online or offline from > the routes configured for a Rails-based application. > > The two libraries can be used separately or together - an JavaScript > client is under independent development for example. Moreover, the > underlying metadata format is framework-neutral; we have been careful > not to “leak” Rails concepts into it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
