Re: Preventing Greedy URL Matching
Hi Jerome,
Cheers. Thanks for the FAQ entry. For whatever reason, I couldn't see
the (now obvious) solution.
From the FAQ:
"Note that after doing this, your Router won't accept URI with query
strings going to this Resource."
Big bummer. Maybe this could be a RFE. Ie. strict matching except for
the query string.
"To solve this, you can explicitely allow the query part in your URI
template:
Route route = router.attach("/users/{user}?{query}", UserResource.class);"
Won't this then _require_ a query string to be attached to the URL? Or
at least require the question mark? In this case, you would need an
additional router.attach("/users/{user}") if you wanted the query string
part to be optional?
Thanks again,
Adam
Jerome Louvel wrote:
Hi Adam,
This is indeed a frequently asked question, but it didn't have a FAQ entry
yet :) So I just had to write it:
http://www.restlet.org/documentation/1.0/faq#24
Best regards,
Jerome
-Message d'origine-
De : Adam Taft [mailto:[EMAIL PROTECTED]
Envoyé : samedi 16 juin 2007 02:16
À : discuss@restlet.tigris.org
Objet : Preventing Greedy URL Matching
Hi,
I'm sure this has got to be a FAQ for Restlet, so sorry in
advance for
such a simple question...
I've got a restlet attached to an example URL like:
/example/{id}/
I want the library to return a 404 for URLs with anything
trailing. Ie.
/example/{id}/foo
/example/{id}/whatever/xyz/blah...
How can I make the matching more "strict" and thus not accept
the extra
path. I can do this manually per request by looking at the
request.getResourceRef().getRemainingPart(). But it's seems kind of
silly to have to do this on every request. Seems like it would be
better a part of the Router matching or something.
Thanks for any advice on this.
By the way, getRemainingPart() returns an empty string for a
request to
/example/{id}/ I'm wondering if this shouldn't return NULL instead.
Related, getSegments() on the above returns: [example, $id, ]
See the
extra item in the segment list?? Yuck.
Thanks,
Adam
RE: Preventing Greedy URL Matching
Hi Adam,
This is indeed a frequently asked question, but it didn't have a FAQ entry
yet :) So I just had to write it:
http://www.restlet.org/documentation/1.0/faq#24
Best regards,
Jerome
> -Message d'origine-
> De : Adam Taft [mailto:[EMAIL PROTECTED]
> Envoyé : samedi 16 juin 2007 02:16
> À : discuss@restlet.tigris.org
> Objet : Preventing Greedy URL Matching
>
> Hi,
>
> I'm sure this has got to be a FAQ for Restlet, so sorry in
> advance for
> such a simple question...
>
> I've got a restlet attached to an example URL like:
>
> /example/{id}/
>
> I want the library to return a 404 for URLs with anything
> trailing. Ie.
>
> /example/{id}/foo
> /example/{id}/whatever/xyz/blah...
>
> How can I make the matching more "strict" and thus not accept
> the extra
> path. I can do this manually per request by looking at the
> request.getResourceRef().getRemainingPart(). But it's seems kind of
> silly to have to do this on every request. Seems like it would be
> better a part of the Router matching or something.
>
> Thanks for any advice on this.
>
> By the way, getRemainingPart() returns an empty string for a
> request to
> /example/{id}/ I'm wondering if this shouldn't return NULL instead.
>
> Related, getSegments() on the above returns: [example, $id, ]
> See the
> extra item in the segment list?? Yuck.
>
> Thanks,
>
> Adam
RE: Programatically creating multipart requests
Hi Joshua, Unfortunately, we don't support client multipart posts yet. You will have to manually use the Apache HTTP client for now. I've updated the existing RFE with this specific request: http://restlet.tigris.org/issues/show_bug.cgi?id=71 Best regards, Jerome > -Message d'origine- > De : Joshua Tuberville [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 15 juin 2007 03:25 > À : discuss@restlet.tigris.org > Objet : Programatically creating multipart requests > > Hi, > > I would like to build a restlet based client but I need to > post a multipart form containing a file as well as > parameters. Is there som way of doing this in the restlet > api like using Part objects in a PostMethod in HttpClient? > > Thanks, > Joshua
RE: Generating URIs for resources
Hi Stian and Adam,
This is indeed a very interesting topic. In the past, a similar mapping from
Resource to URIs was already suggested, reusing the same declarations used
by the Router.
Like you I agree that this is a common need but I'm not really sure yet how
to support this in the API, and in an efficient way. Sometimes several URI
templates can lead to the same Resource so this adds even more complexity.
As for the URI lists, there is already a o.r.d.ReferenceList class that you
can leverage to generate "text/uri-list" representations.
In term of standard for resource lists, I think that WADL could be a good
choice, which I tend to view as an hypermedia content type, programmatic
alternative to HTML.
Best regards,
Jerome
> -Message d'origine-
> De : Adam Taft [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 14 juin 2007 01:54
> À : discuss@restlet.tigris.org
> Objet : Re: Generating URIs for resources
>
> Stian,
>
> Great question / conversation starter...
>
> You're right, this seems to be a common problem that every REST
> developer has to work with. Having some level of support for
> resource
> list generation in RESTlet would be nice.
>
> I don't really have any new ideas for you, as I have to
> generate my own
> list of resource urls in application code. I think it might
> be hard for
> a library to know enough about the application to correctly generate
> urls for it. Some sort of callback interface would be
> required for this
> to work.
>
> At a minimum, I think it would be nice for the library to be able to
> generate lists of resources in "text/uri-list" format, which is one
> resource url per line. Something like:
>
> HTTP/1.1 200 OK
> Content-Type: text/uri-list
> Content-Length: 12345
> ETag: generated by List.hashcode()
>
> http://.../users/jane
> http://.../users/john
> http://...
>
> The advantage here is that you're using a defined "standard" content
> type that has predictable usage and results.
>
> The disadvantage, of course, is that you don't know some nice to have
> additional information about each linked-to resource. For
> example, you
> don't have the 'name' field (in your example, Jane) in the listing.
> Thus a user agent doesn't have much to display except for the
> url itself.
>
> When I get a listing from the server, I want additional
> details for each
> resource. As such, I have defined my own common data transfer object
> called an Entity that I use when generating lists. Included in the
> Entity object are these fields: url, key, last modified,
> etag, display
> text (like 'name')
>
> The biggest point to see here is including information about the etag
> and/or last modified information on the resource. That way, when the
> client performs a GET request for the individual resource,
> the correct
> "If" condition can be added to the HTTP request which allows
> good caching.
>
> Caching is very important, and so having this information
> available as
> part of the list is critical. I don't want to have a list
> returned of
> 100 resources and have to fetch each one. It's quite likely that the
> user has already requested these resources before. (Note
> also the use
> of Etag in the example above).
>
> I honestly don't think there is a "content type" which adequately
> addresses the above requirements. The text/uri-list content type is
> only a CRLF delimited URL listing. However, perhaps we can
> extend the
> standard usage of text/uri-list by adding the above
> functionality. This
> additional functionality could be denoted by a parameter to
> the content
> type.
>
> Here's the above example in this new format...
>
> HTTP/1.1 200 OK
> Content-Type: text/uri-list;expanded
> Content-Length: 12345
> ETag: generated by List.hashcode()
>
> http://.../ ETag=${etag} Last-Modified=${last modified}
> Display=${display}
> http://.../ ETag=${etag} Last-Modified=${last modified}
> Display=${display}
> http://.../ ETag=${etag} Last-Modified=${last modified}
> Display=${display}
>
> Note, the above should be all on one line, not separate word wrapped
> lines. This example uses a ";expanded" parameter to the content type.
>
> If you go with XML, you're going to have a harder time pegging a well
> defined mime type to use. But, that's not to say your can't
> create your
> own in the x-* space. For example: text/x-xml-resource-listing or
> text/x-xml-uri-list or whatever.
>
> If the results are going to be XML based, then using XLINK makes very
> good sense. I don't think xlink has a strict definition for anything
> like "etag" or "last modified," but of course that's not to say the
> generated XML can't have these fields in it.
>
> Anyway, the WHOLE POINT of my message is that once you have defined a
> standard representation for a list of resources, then you are on your
> way to figuring out how to implement it in Restlet code.
> Without having
> that "standard", I don't th
RE: Best way to serve CSS and Javascript from a WAR?
Hi Dustin,
The WAR client is automatically installed when you use the ServerServlet
adapter. In Restlet 1.1, this will work with the standalone mode too, so
Application portability will be intact.
So, you can already simplify your code like this:
public Representation getRepresentation(final Variant variant)
{
return getContext().getDispatcher()
.get("war:///css/{cssfile}").getEntity();
}
Note that going through the context's dispatcher lets you transparently
reuse request's attributes via URI templates :)
Let me know if this works for you.
Best regards,
Jerome
> -Message d'origine-
> De : Dustin N. Jenkins [mailto:[EMAIL PROTECTED]
> Envoyé : mardi 12 juin 2007 16:19
> À : Discussion about Restlet
> Objet : Best way to serve CSS and Javascript from a WAR?
>
> I'm deploying my Restlet application into a WAR in Tomcat, and
> everything seems to be working just fine. Normally, it'd be nicer to
> simply let Tomcat handle the CSS and Javascript files, but I
> want to map
> everything (/*) to the ServerServlet so I can keep the
> initial part of
> the resource ref (i.e. if I were to map /abc/* and /xyz/* I
> wouldn't be
> able to match those because it becomes the base ref and gets stripped
> off).
>
> Here's what I'm doing now for the CSSResource that the
> /css/{cssfile} is
> routed to:
> public Representation getRepresentation(final Variant variant)
> {
> final ServletWarClient warClient =
> new ServletWarClient(getContext(),
> ((ServletContextAdapter)
> getContext()).getServletContext());
>
> return warClient.get("war:///css/"
> +
> getRequestAttribute("cssfile")).getEntity();
> }
>
> Which isn't elegant at all as it's tuned specifically to
> being deployed
> as a WAR, and can no longer be run as a standalone, not to
> mention all
> the implementation specific stuff...
> Is there a better way? I know normal static stuff is served via the
> Directory resource, but it doesn't apply here because everything is
> inside the WAR.
>
> Any suggestions?
> Thank you for the fantastic framework!
>
> Dustin
Re: Servlet Connector and passing per-request attributes
Hi Leigh,
I've implemented the suggested change on the ServletConverter class
only. The code is checked in SVN trunk.
However, I'm relunctant to extend this to the ServletServlet itself
because the target Restlet Application would loose its portability to a
standalone Restlet container.
As you need a tight integration between your Servlet and Restlet code,
direct usage of the ServletConverter class is recommended. If you still
want to go through the ServerServlet, you will just need to create a
subclass that overrides the "getServer()" method like this:
@Override
public HttpServerHelper getServer(HttpServletRequest request) {
HttpServerHelper result = super.getServer(request);
if(this.firstCall){
result.setConverter(
new ServletConverter(getServletContext()));
this.firstCall = false;
}
}
I hope this will help you. BTW, could you let me know why you can't use
the Restlet API directly to establish authentication and resource access
tokens?
Best regards,
Jerome
RE: Conditional GETs?
Hi all,
This RFE is now fixed in SVN trunk and will be testable in the upcoming 1.1
snapshot. Great optimization, thanks Stian for the idea.
Best regards,
Jerome
> -Message d'origine-
> De : Jerome Louvel [mailto:[EMAIL PROTECTED]
> Envoyé : mardi 12 juin 2007 08:55
> À : discuss@restlet.tigris.org
> Objet : Re: Conditional GETs?
>
> Hi Adam,
>
> There is already a "tag" property on the Variant class that you can
> already use. In 1.1, we will simply use this property earlier in the
> algorithm to not call getRepresentation(Variant) when not necessary.
>
> Best regards,
> Jerome
>
>
> Adam Taft a écrit :
> >
> > By the way, I love the suggestion.
> >
> > Can't you add getTag() (or some method) sooner rather than
> later? The
> > default implementation would simply return NULL which would
> then force
> > the algorithm to call getRepresentation() just like it
> currently does.
> >
> > There should be no consequence of this in 1.0.x code?
> >
> > Just curious.
> >
> > Adam
> >
> >
> > Jerome Louvel wrote:
> >> Hi Stian,
> >>
> >> We haven't forgotten about your suggestion, just dealing
> with a long
> >> email
> >> backlog :)
> >> It is perfectly possible to optimize the internal algorithm so that
> >> getRepresentation(Variant) is never called when the variant's tag
> >> matches
> >> the one provided by the client.
> >>
> >> I've entered a RFE to keep track of it:
> >> http://restlet.tigris.org/issues/show_bug.cgi?id=319
> >>
> >> As it changes the observed behavior a bit, it should only go in
> >> Restlet 1.1,
> >> IMHO.
> >>
> >> Best regards,
> >> Jerome
> >>> -Message d'origine-
> >>> De : Stian Soiland [mailto:[EMAIL PROTECTED] Envoyé
> : mercredi
> >>> 6 juin 2007 11:23
> >>> À : discuss@restlet.tigris.org
> >>> Objet : Re: Conditional GETs?
> >>>
> >>>
> >>> On 4 Jun 2007, at 15:53, Peter Lacey wrote:
> >>>
> public Representation getRepresentation(Variant variant) {
> Representation result = null;
>
> if
> (variant.getMediaType().equals(MediaType.APPLICATION_XML)) {
>
> // create DOM
>
> result = new
> DomRepresentation(MediaType.APPLICATION_XML,
> doc);
> result.setTag(new Tag([your etag], false));
> }
> return result;
> }
> >>> It's really clever, except you still have to create that XML
> >>> representation that never needs to be sent out.
> >>>
> >>> If there was some getTag() method or something you could
> override
> >>> this to check directly with the database on whatever you need to
> >>> calculate the tag, and hence getRepresentation() wouldn't
> even need
> >>> to be called.
> >>>
> >>> To support this I think some kind of getLastModified() would also
> >>> be cool. (I've made such a thing in my subclass of Resource)
> >>>
> >>> --
> >>> Stian Soiland, myGrid team
> >>> School of Computer Science
> >>> The University of Manchester
> >>> http://www.cs.man.ac.uk/~ssoiland/
> >>>
> >
RE: Date and time in access log format
Hi Jim, This isn't supported yet, which is unfortunate when you need a custom log format. The default format is hard-coded in Java, that's why I forgot to add it to the Template class. I've entered a RFE for 1.1: http://restlet.tigris.org/issues/show_bug.cgi?id=320 Best regards, Jerome > -Message d'origine- > De : news [mailto:[EMAIL PROTECTED] De la part de Jim Edwards-Hewitt > Envoyé : vendredi 8 juin 2007 23:56 > À : discuss@restlet.tigris.org > Objet : Date and time in access log format > > How can I specify date and time (and if possible, their > format) in a custom > LogService format? They are included in the default format, > but the docs for > setLogFormat() refer to Template, and I don't see any > variables in Template for > transaction date and time. (It would be helpful to have in > the docs a format > string that replicates the default format, too.) > > Thanks, > > -- Jim >
