Re: Restlet presentation slides
On 20/03/07, Jerome Louvel [EMAIL PROTECTED] wrote: Last week, Sean Landis made a very nice presentation about the Restlet project at the Utah Java Users Group. The slides as well as the sample code are publicly available on our Wiki and I encourage everyone to check them out and to share them with people interested in REST and Restlet: http://wiki.restlet.org/#Presentations I would like to congratulate him for writing such a detailed presentation and for communicating about Restlets to the wider Java community. And communicating so clearly! Very well presented. Thanks Sean. Are you going to announce on the rest list? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
RE: Restlet presentation slides
Hi Dave, Good idea, I've just posted a related announcement to the REST list: http://tech.groups.yahoo.com/group/rest-discuss/message/8146 Best regards, Jerome -Message d'origine- De : Dave Pawson [mailto:[EMAIL PROTECTED] Envoyé : mardi 20 mars 2007 12:11 À : discuss@restlet.tigris.org Objet : Re: Restlet presentation slides On 20/03/07, Jerome Louvel [EMAIL PROTECTED] wrote: Last week, Sean Landis made a very nice presentation about the Restlet project at the Utah Java Users Group. The slides as well as the sample code are publicly available on our Wiki and I encourage everyone to check them out and to share them with people interested in REST and Restlet: http://wiki.restlet.org/#Presentations I would like to congratulate him for writing such a detailed presentation and for communicating about Restlets to the wider Java community. And communicating so clearly! Very well presented. Thanks Sean. Are you going to announce on the rest list? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
Getting the ServletContext (if you really have to) in 1.0RC5
I have an existing web application that uses Spring in Tomcat, and I've added a REST API to it using Restlets with RC4. I use the Noelios ServerServlet as the entry point. But when I create my root Restlet, I need to get at business objects that are already created in a Spring (web) context. For that reason, the Noelios Spring extension (SpringContext) doesn't really work for me. I can't load my own beans from an XML file, because my own Restlets have dependencies on other domain objects in the Spring world. What I did to make this work in RC4 was to, in my Application.createRoot() method, use this one line of evil code: WebApplicationContext wac = WebApplicationContextUtils.getWebApplicationContext( ((ServletContextAdapter)getContext()).getServletContext() ); That uses Spring's WebApplicationContextUtils to get the existing Spring context from the ServletContext. To get the Servlet context, I have to hack the current RestContext by casting it to the ServletContextAdapter that it really is. This is obviously not _right_, so naturally when I tried to upgrade to RC5 it broke. I think that's because the Context setup by the new ServerServlet has additional wrapper(s) or something. So, (1) at first glance I didn't even see how to port my hack. Is there a hackish way to get the ServletContext in RC5? (2) Any suggestions for the right way to do this? My first inclination would be to subclass ServerServlet with something of my own that makes the ServletContext available. Sorry for the long post. I thought this might be a common use-case for Spring users out there, so the answer(s) might benefit many. Stokes.
Router and URLs with extra stuff at the end
If I have a router with two Restlets attached as follows:
/foos == FooListFinder
/foos/{fooId} == FooFinder
... then, as expected, these request route as follows:
/foos --routes to-- FooListFinder
/foos?somearg=true --routes to-- FooListFinder
/foos/123 --routes to-- FooFinder
/foos/123?someotherarg=456 --routes to-- FooFinder
All of that is good.
But as a side-effect, I get these that I _don't_ want:
/foos/123/garbage --routes to-- FooFinder
/foos/123/more/garbage --routes to-- FooFinder
Any suggestions for how to prevent these last two? I need to handle this at the
framework/router level, so that the Finder implementations aren't concerned.
In my case my API is very particular about syntax, so I want the last two
requests above to result in an error page (400).
Thanks,
Stokes.
MediaType.APPLICATION_RDF
Just a quick note; technically speaking RDF isn't a media type, but rather a data model. There are several serializations of RDF, the most popular being RDF/XML (let's call it APPLICATION_RDFXML?), but there are others, like N3, etc. that are quite popular. It might be a good idea, before going 1.0, to clarify this by renaming APPLICATION_RDF to APPLICATION_RDFXML and adding APPLICATION_RDF_N3, and APPLICATION_RDF_NTRIPLE Also, philosophical question: is it really the case that we can assume a 1-1 mapping between a MediaType and a Mime-Type? Mime-type application/rdf+xml is the correct mime-type for RDF/XML, but in reality some frameworks (like Mozilla's RDF stuff) expect it in application/xml .. I'm hacking around this in my RDFXMLRepresentation, but it seems inelegant as it stands. Ryan -- Ryan Daum [EMAIL PROTECTED] Senior Developer, Toronto 647.724.5232 x 2073
Re: MediaType.APPLICATION_RDF
Correction, I believe that should be TEXT_RDF_N3 and TEXT_RDF_NTRIPLE On 3/20/07, Ryan Daum [EMAIL PROTECTED] wrote: Just a quick note; technically speaking RDF isn't a media type, but rather a data model. There are several serializations of RDF, the most popular being RDF/XML (let's call it APPLICATION_RDFXML?), but there are others, like N3, etc. that are quite popular. It might be a good idea, before going 1.0, to clarify this by renaming APPLICATION_RDF to APPLICATION_RDFXML and adding APPLICATION_RDF_N3, and APPLICATION_RDF_NTRIPLE Also, philosophical question: is it really the case that we can assume a 1-1 mapping between a MediaType and a Mime-Type? Mime-type application/rdf+xml is the correct mime-type for RDF/XML, but in reality some frameworks (like Mozilla's RDF stuff) expect it in application/xml .. I'm hacking around this in my RDFXMLRepresentation, but it seems inelegant as it stands. Ryan -- Ryan Daum [EMAIL PROTECTED] Senior Developer, Toronto 647.724.5232 x 2073 -- Ryan Daum [EMAIL PROTECTED] Senior Developer, Toronto 647.724.5232 x 2073
Re: Router and URLs with extra stuff at the end
Hello Stokes,
The routing mechanism is based on Template objects
(http://www.restlet.org/documentation/1.0/api/index.html?org/restlet/util/Template.html)
and Variable objects.
When defining a route with the attach method, a Template object is
created and then associated with this route. This Template object is
in charge of parsing the requested URI and give it a score according to
some attributes. then the Router can compare the score of each route
defined and choose the one it prefers ([1]).
The way the Template object assigns a score can be customized with the
following modes :
- MODE_START_WITH (default)
- MODE_EQUALS
In order to solve your problem, you can use the equals mode :
//Define routing to FooListFinder
component.getDefaultHost().attach(/foos, FooListFinder);
//Define routing to FooFinder
Route route = component.getDefaultHost().attach(/foos/{fooid},
FooFinder);
route.getTemplate().setMatchingMode(Template.MODE_EQUALS);
route =
component.getDefaultHost().attach(/foos/{fooid}?{fooQuery}, ,
FooFinder);
route.getTemplate().setMatchingMode(Template.MODE_EQUALS);
//In this case, the variable fooQuery is redefined : it's a
query variable, and it is not required (in order to allow such URIs :
/foos/123?).
Variable variable = new Variable(Variable.TYPE_URI_QUERY, ,
false, false);
route.getTemplate().getVariables().put(fooQuery, variable);
I hope this helps you.
Best regards,
Thierry Boileau
PS :
[1] 6 modes are available :
* Best match (default)
* First match
* Last match
* Random match
* Round robin
* Custom
If I have a router with two Restlets attached as follows:
/foos == FooListFinder
/foos/{fooId} == FooFinder
... then, as expected, these request route as follows:
/foos --routes to-- FooListFinder
/foos?somearg=true --routes to-- FooListFinder
/foos/123 --routes to-- FooFinder
/foos/123?someotherarg=456 --routes to-- FooFinder
All of that is good.
But as a side-effect, I get these that I _don't_ want:
/foos/123/garbage --routes to-- FooFinder
/foos/123/more/garbage --routes to-- FooFinder
Any suggestions for how to prevent these last two? I need to handle this at the
framework/router level, so that the Finder implementations aren't concerned.
In my case my API is very particular about syntax, so I want the last two
requests above to result in an error page (400).
Thanks,
Stokes.
RE: Router and URLs with extra stuff at the end
Hi Stokes,
Depending on the type of routing it maybe desirable to require an exact
match of the target URI (like in your case) or simply a match of the start
of the target URI (like in the case of a Directory finder).
The Router class uses the second mode (Template.START_WITH) by default when
you use the attach(uriTemplate, next) method. You can change this to the
stricter EQUALS mode by doing something like:
Route route = myRouter.attach(/foos/123, myFooFinder);
route.getTemplate().setMatchingMode(Template.MODE_EQUALS);
Best regards,
Jerome
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Stokes
Envoyé : mardi 20 mars 2007 16:01
À : discuss@restlet.tigris.org
Objet : Router and URLs with extra stuff at the end
If I have a router with two Restlets attached as follows:
/foos == FooListFinder
/foos/{fooId} == FooFinder
... then, as expected, these request route as follows:
/foos --routes to-- FooListFinder
/foos?somearg=true --routes to-- FooListFinder
/foos/123 --routes to-- FooFinder
/foos/123?someotherarg=456 --routes to-- FooFinder
All of that is good.
But as a side-effect, I get these that I _don't_ want:
/foos/123/garbage --routes to-- FooFinder
/foos/123/more/garbage --routes to-- FooFinder
Any suggestions for how to prevent these last two? I need to
handle this at the
framework/router level, so that the Finder implementations
aren't concerned.
In my case my API is very particular about syntax, so I want
the last two
requests above to result in an error page (400).
Thanks,
Stokes.
Re: Router and URLs with extra stuff at the end
Ooops,
I forget : you also need to set the equals mode when routing to
fooListFinder, otherwise this route will catch the garbage URLs.
Best regards,
Thierry Boileau
Hello Stokes,
The routing mechanism is based on Template objects
(http://www.restlet.org/documentation/1.0/api/index.html?org/restlet/util/Template.html)
and Variable objects.
When defining a route with the attach method, a Template object is
created and then associated with this route. This Template object is
in charge of parsing the requested URI and give it a score according
to some attributes. then the Router can compare the score of each
route defined and choose the one it prefers ([1]).
The way the Template object assigns a score can be customized with the
following modes :
- MODE_START_WITH (default)
- MODE_EQUALS
In order to solve your problem, you can use the equals mode :
//Define routing to FooListFinder
component.getDefaultHost().attach(/foos, c);
//Define routing to FooFinder
Route route =
component.getDefaultHost().attach(/foos/{fooid}, FooFinder);
route.getTemplate().setMatchingMode(Template.MODE_EQUALS);
route =
component.getDefaultHost().attach(/foos/{fooid}?{fooQuery}, ,
FooFinder);
route.getTemplate().setMatchingMode(Template.MODE_EQUALS);
//In this case, the variable fooQuery is redefined : it's a
query variable, and it is not required (in order to allow such URIs :
/foos/123?).
Variable variable = new Variable(Variable.TYPE_URI_QUERY, ,
false, false);
route.getTemplate().getVariables().put(fooQuery, variable);
I hope this helps you.
Best regards,
Thierry Boileau
PS :
[1] 6 modes are available :
* Best match (default)
* First match
* Last match
* Random match
* Round robin
* Custom
If I have a router with two Restlets attached as follows:
/foos == FooListFinder
/foos/{fooId} == FooFinder
... then, as expected, these request route as follows:
/foos --routes to-- FooListFinder
/foos?somearg=true --routes to-- FooListFinder
/foos/123 --routes to-- FooFinder
/foos/123?someotherarg=456 --routes to-- FooFinder
All of that is good.
But as a side-effect, I get these that I _don't_ want:
/foos/123/garbage --routes to-- FooFinder
/foos/123/more/garbage --routes to-- FooFinder
Any suggestions for how to prevent these last two? I need to handle
this at the
framework/router level, so that the Finder implementations aren't
concerned.
In my case my API is very particular about syntax, so I want the last
two
requests above to result in an error page (400).
Thanks,
Stokes.
