aspose file tools*
The moose likes Web Services and the fly likes Trouble using URI fragments with RESTful services and Tomcat 6 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Trouble using URI fragments with RESTful services and Tomcat 6" Watch "Trouble using URI fragments with RESTful services and Tomcat 6" New topic
Author

Trouble using URI fragments with RESTful services and Tomcat 6

Jake Beard
Greenhorn

Joined: Oct 06, 2009
Posts: 6
Hi all,

I'm getting my first chance to play around with RESTful web services for a class project. My intention was to come up with a URI schema for addressing web resources that looked like this:

http://domain/<servlet_container_name>/<servlet_name>/<document_name>#<object_id>;

So it would be possible to POST to http://domain/<servlet_container_name>/<servlet_name>/<document_name>; in order have a new subordinate object (a new element of the document document_name) dynamically created, with a unique object_id assigned by the server; and it would be possible to PUT to
http://domain/<servlet_container_name>/<servlet_name>/<document_name>#<object_id>; in order to create a new object with the specified id object_id, which would be a subordinate element in the document document_name.

Unfortunately, in Tomcat at least, the fragment part of the URI seems to be getting stripped. So, for example, a request to

http://localhost:8080/DistributedGraphics/FirstServlet/foo.svg#bar

for every method, shows up as
http://localhost:8080/DistributedGraphics/FirstServlet/foo.svg on request.getRequestURL(). The fragment gets cut out.

I'm quite new to REST, so I'm not sure if this is expected behaviour, or a feature of Tomcat. Conceptually, I like this way of addressing resources, as the URI fragment makes it very clear that I'm referring to an element in a particular document. But maybe this is actually something that one should not do with REST, and that's why the URI fragment is being automatically removed.

If anyone has any insight into this, I would greatly appreciate it if you would let me know.

Thanks,

Jake
Travis Hein
Ranch Hand

Joined: Jun 06, 2006
Posts: 161
I think all containers that implement the Servlet API would only support URLs as of the RFC 1738 specification,
The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it.


What if you were to url encode the # on the sender and then have the servlet look for the %23 and parse that out.

but just as easily, would you be able to specify the item as a get parameter,

http://localhost:8080/DistributedGraphics/FirstServlet/foo.svg?bar

this would be available through the request.getParameterNames() , which returns an enum of param names and if you only ever expect 1 thing here you would not need to specify the value. just the visual effect of replacing teh # with the ?


Error: Keyboard not attached. Press F1 to continue.
Jake Beard
Greenhorn

Joined: Oct 06, 2009
Posts: 6
Travis Hein wrote:
but just as easily, would you be able to specify the item as a get parameter,

http://localhost:8080/DistributedGraphics/FirstServlet/foo.svg?bar

this would be available through the request.getParameterNames() , which returns an enum of param names and if you only ever expect 1 thing here you would not need to specify the value. just the visual effect of replacing teh # with the ?


Great idea. I like the hash, because it seems to most closely match the semantics I'm trying to express, but it's clearly unsafe, so I shouldn't use it. Your suggestion seems like a good alternative, and will likely be very easy to program. Hopefully I'm not missing any other subtleties here.

Thanks again,

Jake

Update: works like a charm
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Trouble using URI fragments with RESTful services and Tomcat 6