Mike Burrows (asplake)
2009-May-07 13:05 UTC
[ANN] Manifesto and roadmaps for described_routes and path-to
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) at http://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 mjb-BORgDpnuIjAqdlJmJB21zg@public.gmane.org http://positiveincline.com http://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.
Mike Burrows (asplake)
2009-May-08 10:21 UTC
Re: Manifesto and roadmaps for described_routes and path-to
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...-BORgDpnuIjAqdlJmJB21zg@public.gmane.org> 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...-BORgDpnuIjDJf6X9iFXN5ngSJqDPrsil@public.gmane.org://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.