Hi Nic, Thanks for this constructive feed-back.
The core Restlet API is a rather low-level API, comparable to the Servlet API but carefully designed to support REST/HTTP and to be as protocol neutral as possible. You can definitely build your Web services on top of a pure HTTP API like Jetty, Simple, AsyncWeb, etc. (we do it internally for our HTTP connectors), but you loose many abstractions (like HTTP headers parsing logic) and extra features. Also, the core Restlet API doesn't intend to provide support for all the potential needs all the way up to your domain logic. This is more the role of the Restlet API extensions (see org.restlet.ext.* packages). But we do intend to support parameter extraction and validation at this level too, especially the generic and reusable logic. The highest-level in the API is the Resource class which should contain your important business/domain logic. Everything before that should be as simple as possible for the developer and cover: URI-based request routing, parameter extraction and validation, content negotiation, application management, virtual host support, authentication, etc. Back to your problem, we already provide support for parameter extraction, first via the URI templates (see http://www.restlet.org/tutorial#part11) and via an org.restlet.Extractor filter that helps to extract parameters from the query or body forms. This filter has been enhanced and merged with Scorer to become the new Route class in SVN (see upcoming RC1 release). Also the Form class has a "copyTo(Map)" method that can help to read only a set of expected parameters, ignoring the rest. I would be definitely interested to see your actual validation code and discuss with you how we should improve the validation support in the Restlet API. Best regards, Jerome > -----Message d'origine----- > De : news [mailto:[EMAIL PROTECTED] De la part de Nic Pottier > Envoyé : vendredi 15 décembre 2006 21:54 > À : [email protected] > Objet : Why I built my own.. > > I was looking into Restlets to allow me to more quickly write > some web > services. Sadly I didn't find that to be the case. Figured > I'd explain > why and what I quickly built instead to scratch my itch. > Admittedly I > only spent half a day play with Restlets, so my impressions > have to be > taken with a grain of salt and might very well be wrong. > > I have the need to expose a few fairly simple APIs via a web service. > RESTish APIs are by far my preferred method for doing this, mostly > because they are so easily testable via a browser, easily > load balanced > and integrate in various languages easily. > > I built a quick image transcoding / scaling Restlet > yesterday. Although > it was fairly straight forward, the framework didn't really > make things > EASIER for me. I found myself writing a lot of code to validate the > parameters I expected were included in the request, pulling them out, > making sure they were the correct format etc.. then handling those > cases and returning appropriate error messaging and status > codes. The > actual WORK for the service was one method, which honestly I should > refactor into it's own library. > > I guess the point is that in the vast majority of well > designed systems, > the actual logic to a RESTlet should be exceedingly simple. > IE, if you > are providing a view into a database, or doing some unit of > work, that > code likely lives in a separate library entirely. The framework > (Restlet or otherwise) should be doing the heavy lifting of doing > parameter parsing and validation, since that's really all we > are doing, > putting a thin web service veneer on functionality we have > already built. > > Sadly, I didn't find that the Restlet framework was really making my > life any easier. > > Instead I wrote a thin layer over Jetty that DID satisfy that need. > I'll explain it here only because I think it might be worthy > of discussion. > > I defined a Parameter interface which when handed a Request > will extract > named value(s) from it. From this I've derived a bunch of > different > Parameter types (Path, Query, Body, Derived). Each parameter can > specify whether it is a required parameter, as well as a regular > expression which the parameter MUST match if present. RestStop's (my > base end point) expose a List of the Parameter's they expect. The > framework takes care of taking an incoming request, parsing the > parameters and displaying appropriate error messaging in case of > failure. The framework guarantees that when handle() is called on > RestStop all required parameters are present and pass format > validation. > This GREATLY simplified my code. > > Additionally, I created greatly simplified Request and > Response objects > which only exposed the incoming parameter values and outgoing > template > values. (or optionally an output stream to write to) The primary > purpose there being that unit testing of RestStops is dead > simple. You > simply fill a hash with your test input parameters, call handle() and > validate that the output hash is as expected. > > I hooked up FreeMarker for simple templating. > > I don't claim that this setup is near as powerful or flexible as > Restlets, but it does lead to vastly faster (and I believe safer and > more correct) service implementations. > > If you are interested, I'd be happy to share the code. There > isn't much > there but it does what it does well. > > -Nic > >
