Note that there are some explanatory texts on larger screens.

plurals
  1. POHow should I create a REST API using Rails 3.0?
    text
    copied!<p>I can't seem to find much information on the web about the different approaches to building a REST API in Rails; so I kinda have two questions:</p> <ol> <li><strong>Can someone point me to some articles that show the pros/cons of the different approaches?</strong></li> <li><strong>Would you please share your thoughts on the pros/cons of the following approaches?</strong></li> </ol> <p>&nbsp;</p> <h2>Proposed Approaches</h2> <p>&nbsp; </p> <ol> <li><p><strong>Use the standard controllers to return XML when a users adds <code>.xml</code> to the end of the URL</strong></p> <p><strong><em>Pros:</em></strong></p> <ul> <li>This is built-in to Rails and very easy to use</li> <li>Follows the same resource-based approach that Rails has, so it will be easy for existing users to understand/remember <h1> </h1></li> </ul> <p><strong><em>Cons:</em></strong></p> <ul> <li>API isn't cleanly separated from the main site, harder to maintain</li> <li>People may assume that adding <code>.xml</code> will work in places it doesn't <h1> </h1></li> </ul></li> <li><p><strong>Use namespaced routing to create separate API controllers that only handle API functions, but still have access to the same models that the website uses</strong></p> <p><strong><em>Pros:</em></strong></p> <ul> <li>API is mostly separated</li> <li>Still uses resource-full controllers</li> </ul> <h1> </h1> <p><strong><em>Cons:</em></strong></p> <ul> <li>URLs have the form of site.com/api/resource.xml which may make people assume all resources are available</li> <li>API is still part of the website code/project; thus, harder to maintain</li> </ul> <h1> </h1></li> <li><p><strong>Use route forwarding and constraints to forward all API calls to a Rack application</strong></p> <p><strong><em>Pros:</em></strong></p> <ul> <li>API is fully separated</li> <li>Not required to use Resource-full style if we don't want to</li> <li>URLs clearly show it's an API and you should check the docs to see what's available (at least, my mind works this way; I assume other dev's minds do too)</li> </ul> <h1> </h1> <p><strong><em>Cons:</em></strong></p> <ul> <li>Harder to use models from website code</li> <li>Easier to maintain as a separate project, but that means harder to integrate with existing site</li> <li>Must keep codebases in sync since models may change for site features/bug fixes</li> </ul> <h1> </h1></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload