RESTstop<\/a> is a Ruby library making it easy to implement REST<\/a> services \t\t\t\t\t Before jumping to RESTstop<\/a> (if you insist click here<\/a>), let’s do a brief review of the few options, <\/p>\n <\/p>\n <\/p>\n Since Camping<\/a> is a generic Ruby web application framework, you can define service endpoints as url routes<\/a>, Such as an approach is fine for function-oriented APIs<\/i> but if we want to provide CRUD access to resources<\/a>, \t\t\t\t\t<\/a>\t<\/p>\n Matt Zukowski<\/a> wrote the RESTstop<\/a> library to easily provide access to REST resources<\/a> using the underlying Camping route engine and controllers. Then similarly to the standard get<\/b> and post<\/b> methods of Camping controllers, you would create CRUD-style<\/b> action methods Then once you had a controller, you would implement a special type of view<\/b> appropriate for the format of the data you wanted to expose. RESTstop<\/a> is an interesting plugin to dissect as it is a good illustration of meta-programming<\/a> in Ruby. I would definitely recommend that your read the plugin's source. At 449 lines with many comments Here is an outline of the approach:<\/p>\n
\n\t\t\t\t\ton top of the Camping framework<\/a>.<\/p>\n
<\/p>\nWeb Services Implementation Options<\/h3>\n
\n\t\t\t\t\tdevelopers have historically leveraged to build web services:<\/p>\n\n
\n\t\t\t\t\t\tAdditional services can be composed on top of the basic protocol to provide authentication, authorization, etc.
\n\t\t\t\t\t\tAlthough powerful, SOAP has proven too complex<\/b> and too heavy<\/b> for web developer APIs .
\n\t\t\t\t\t\tAlso they require a full SOAP-compatible client stack<\/b> for making them more difficult to call especially in the case of AJAX applications.
\n\t\t\t\t\t\tAs a consequence, SOAP services tend to have been relegated to intra-enterprise cross-application services<\/b>. <\/li>\n
\n\t\t\t\t\t\tEach service has a given url and uses XML to represent messages. As such an XML parser<\/b> is required to provide robust processing
\n\t\t\t\t\t\tespecially if the data structures are complex and rely on namespaces.<\/li>\n
\n\t\t\t\t\t\tMessages are represented as JSON<\/a> structures.
\n\t\t\t\t\t\tJSON<\/a> services lend themselves very well to AJAX<\/b> calls from browser applications since
\n\t\t\t\t\t\tJSON<\/a> structures can be easily processed using basic Javascript.<\/li>\nCamping for Web Services<\/h3>\n
\n\t\t\t\t\teach mapped to a given controller<\/b>.
\n\t\t\t\t\tAn HTML-based view is not necessary obviously, so instead one option is to render the model
\n\t\t\t\t\tusing the desired format: XML<\/b> or JSON<\/a>.
\n\t\t\t\t\tExample:\n\t\t\t\t\t<\/p>\n\r\ngem 'camping' , '>= 2.0'\t\r\n%w(rubygems active_support active_support\/json active_record camping camping\/session markaby erb ).each { | lib | require lib }\r\n\r\nCamping.goes :CampingJsonServices\r\n\r\nmodule CampingJsonServices\r\n\tinclude Camping::Session\r\n\r\n\tdef CampingJsonServices.create\r\n\tend\r\n\r\n\tmodule CampingJsonServices::Controllers\r\n\r\n\t\tclass APIDateToday < R '\/datetoday'\r\n\t\t\tdef get\r\n\t\t\t\t@result = {:today=>Date.today.to_s}\r\n\t\t\t\t\r\n\t\t\t\t@headers['Content-Type'] = \"application\/json\"\r\n\t\t\t\t@result.to_xml(:root=>'response')\r\n\t\t\tend\r\n\t\tend\r\n\r\n\t\tclass APITimeNow < R '\/timenow'\r\n\t\t\tdef get\r\n\t\t\t\t@result = {:now=>Time.now.utc.to_s}\r\n\t\t\t\t\r\n\t\t\t\t@headers['Content-Type'] = \"application\/json\"\r\n\t\t\t\t@result.to_json\r\n\t\t\tend\r\n\t\tend\r\n\r\n\tend\r\nend\t\r\n<\/pre>\n
\n\t\t\t\t\tthen a REST<\/a> approach provides more structure. You can of course implement a REST<\/a>-style API on your own
\n\t\t\t\t\tby overriding the route dispatch mechanism and mapping the HTTP verbs such as PUT and DELETE
\n\t\t\t\t\tto the appropriate route controller methods.\n\t\t\t\t\t<\/p>\nRESTstop, a REST plugin for Camping<\/h3>\n
\n\t\t\t\t\tThe idea was powerful yet simple, as a developer you would create a controller per resource<\/a>
\n\t\t\t\t\tand specify the REST<\/a> nature of the route like so:<\/p>\n\r\nmodule Blog::Controllers\r\n extend Reststop::Controllers\r\n\r\n\tclass Posts < REST 'posts' \r\n\tend\r\nend\r\n<\/pre>\n
\n\t\t\t\t\tsuch as: create<\/b>, read<\/b>, update<\/b>, delete<\/b>, and list<\/b>:<\/p>\n\r\nclass Posts < REST 'posts' \r\n # POST \/posts\r\n def create \r\n end\r\n\r\n # GET \/posts\/1\r\n # GET \/posts\/1.xml\r\n def read(post_id)\r\n end\r\n\r\n # PUT \/posts\/1\r\n def update(post_id)\r\n end\r\n\r\n # DELETE \/posts\/1\r\n def delete(post_id)\r\n end\r\n\r\n # GET \/posts\r\n # GET \/posts.xml\r\n def list\r\n\tend\r\nend\r\n<\/pre>\n
\n\t\t\t\t\tFor example you could create views to render the data as XML or JSON<\/a> or any other format you liked.<\/p>\n\r\nmodule Blog::Views\r\n extend Reststop::Views\r\n \r\n module HTML\r\n include Blog::Controllers\r\n include Blog::Views\r\n\t\r\n def index\r\n if @posts.empty?\r\n p 'No posts found.'\r\n else\r\n for post in @posts\r\n _post(post)\r\n end\r\n end\r\n p { a 'Add', :href => R(Posts, 'new') }\r\n end\r\n\t\r\n end\r\n \r\n module XML\r\n include Blog::Controllers\r\n include Blog::Views\r\n\t\r\n def index\r\n @posts.to_xml(:root => 'blog')\r\n end\r\n\t\r\n end\r\n \r\n module JSON\r\n include Blog::Controllers\r\n include Blog::Views\r\n\t\r\n def index\r\n @posts.to_json\r\n end\r\n end\r\n\t\r\n<\/pre>\nThe Inner Plumbing Of RESTstop<\/h3>\n
\n\t\t\t\t\tMatt<\/a> took the following approach:<\/p>\n\n
\n\t\t\t\t\t\t\tThe new method will register all the expected REST resource routes and wire them up to the controller.<\/li>\n
\n\t\t\t\t\tit is pretty easy to see how it actually works. This will also make it easier for you to troubleshoot your code when needed.<\/p>\nLet's Create The REST Version Of The Blog Sample<\/h3>\n
<\/p>\n
\n\t\t\t\t<\/p>\n
\n\t\t\t\t<\/p>\n
\n\t\t\t\t<\/p>\n
\n\t\t\t\t<\/p>\n
\n\t\t\t\t<\/p>\n
<\/p>\n
\n\t\t\t\t<\/p>\n
\n\t\t\t\t<\/p>\n