Cheers for that -- I don't think (after a quick semi-peruse of the page)
that this is for writing web servers (that receive & send JSON, for
example, & never render to a screen).
Although please correct me if I'm wrong.
No, the app I have in mind could well become quite complex internally --
it's just a web service, not a web site.
Although, Camping does look rather cool!
Cheers again,
Doug.
You have at least a couple of options for the web server (I'm assuming
you're mainly interested in writing your app, not implementing a web
server):
1. WEBRick
2. Mongrel
Both of these support 'servlets' - not the same as Java servlets, as
in, not the exact same API as the servlet API, but something roughly
similar (though their API's are much simpler and smaller in size).
In outline, do something like this:
- Create an instance of a server (see the WEBrick / Mongrel docs for
the exact class name).
- Write your app-specific classes, each of which you want to expose as
a REST resource, i.e. give them Ruby methods corresponding to the HTTP
methods GET, POST, PUT, DELETE, etc.
- Write a 'controller' class that reads the request URI and decides
which of your app-specific classes to delegate the request to. E.g. in
its doGET method, delegate to the 'get' method of the appropriate
class (determined by checking the incoming request URI). If the method
is GET, the parameters in the URI should be passed as arguments to
your class's 'get' method, including an optional one that says what
format the client wants the response in (e.g.: HTML/XML/JSON).
- 'Mount' this class on the server.
- Start the server.
- For each request that comes in, your controller gets control, does
as said above (delegates the request), and then the the return value
from the appropriate method of your class, as HTML/XML/JSON. is sent
to the client as the response.
Note: The above approach is for if you have multiple app-specific
classes / instances that you want to expose as REST resources. If you
have only one, things can be simpler - the 'controller' class itself
can be the main or only app-specific class. Then, in its doGET method,
just return the representation of the resource, appropriately
formatted (as HTML/XML/JSON).
On the client end, you'll have to read and parse the response, and do
whatever you want to, with it. (If your client is a browser, you may
not have to do anything. Just let the user interact with the server
using the browser, e.g. clicking links in the response.) E.g. Display
it, allow the user to interact with the data shown, including clicking
links that trigger new REST requests, etc. For parsing the XML you can
use REXML, for JSON, there's a JSON library for Ruby (ruby-json? -
GIYF).
For sending the requests, use open-uri or Net:HTTP.
(The WEBrick and Mongrel API's provide support for some of the above
steps, i.e. creating the server and mounting your classes on it. The
rest is app-specific and up to you.)
The book "RESTful Web Services" from O'Reilly, by Leonard Richardson
and Sam Ruby, is a great resource for what you're trying to do (IMO).
I got it recently and have read some of it. If you can, get it, then
it should be a snap to do what you need.
Also read the WEBRick or Mongrel docs for their server and servlet
classes. GIYF again ...
The book authors mention some limitations with open-uri for REST work
(doesn't support all HTTP methods, among other things), which they fix
by writing another library - rest-open-uri - on top of it, which you
can probably get from the source code link for the book at the book's
web page on the O'Reilly site.
Also, 'Enterprise Integration with Ruby' by Maik Schmidt, from the
Pragmatic Bookshelf, has some good examples of writing WEBrick
servlets.
HTH
Vasudev
-----------------------------------------
Vasudev Ram
http://www.dancingbison.com
http://jugad.livejournal.com
http://sourceforge.net/projects/xtopdf
-----------------------------------------
