# \[ANN\] Manifesto and roadmaps for described\_routes and path-to

**URL:** <https://www.ruby-forum.com/t/ann-manifesto-and-roadmaps-for-described-routes-and-path-to/167432>\
**Category:** Rails\
**Created:** [May 7, 2009, 6:33pm UTC](https://www.ruby-forum.com/t/ann-manifesto-and-roadmaps-for-described-routes-and-path-to/167432 "2009-05-07T18:33:36Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![asplake](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/2bfe46/32.png) [@asplake](https://www.ruby-forum.com/u/asplake)\
**Post date:** [May 7, 2009, 6:33pm UTC](https://www.ruby-forum.com/t/ann-manifesto-and-roadmaps-for-described-routes-and-path-to/167432/1 "2009-05-07T18:33:36Z")

</div>

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  
[Positive Incline | Agendashift](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  
removed\_email\_address@domain.invalid

> **[Positive Incline](https://blog.agendashift.com/positive-incline/)**
>
> Positiveincline.com – once Mike’s personal blog – now redirects to blog.agendashift.com. If the destination page exists, you’ll go right to it. If it doesn’t, you land here! Posts…

[http://twitter.com/asplake](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.

---

<div class="post-metadata">

**Author:** ![asplake](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/2bfe46/32.png) [@asplake](https://www.ruby-forum.com/u/asplake)\
**Post date:** [May 8, 2009, 12:22pm UTC](https://www.ruby-forum.com/t/ann-manifesto-and-roadmaps-for-described-routes-and-path-to/167432/2 "2009-05-08T12:22:29Z")

</div>

This might make more sense with a concrete example - see

> <https://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](http://positiveincline.com/?p=254).

Mike

On May 7, 2:05 pm, “Mike Burrows (asplake)” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)