FYI, I've just entered a report to keep track of this discussion: "Improve parameter validation" http://restlet.tigris.org/issues/show_bug.cgi?id=221
Thanks, Jerome > -----Message d'origine----- > De : Jerome Louvel > Envoyé : lundi 18 décembre 2006 14:53 > À : [email protected] > Objet : RE: Why I built my own.. > > > 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 > > > >
