Hi Chuck, I agree with the AWWW sections that you mentioned and still see value in localizing the URIs even if they technically correspond to the same resource. The exposed representations and content negotiation could be adapted based on the URI used to get them.
More importantly, the same application instance could be attached to multiple virtual hosts, and still consider that requests from each host point to completely separate resources. For example, let's consider that Yahoo! has a forum application, it could attach it to http://groups.yahoo.com and http://groups.yahoo.ca. This application could know that http://groups.yahoo.com/group/rest-discuss/ exists and that http://groups.yahoo.ca/group/rest-discuss/ doesn't. Nothing prevent them for distinguishing different URIs and from taking the URI authority into account when processing requests. Nonetheless, I understand the problem that you are currently facing and the need to host information at initialization time. Thanks for detailing your use case. If you were using the standalone Restlet mode, you could easily workaround it by specifying application parameters. When we support WAR style packaging in 1.1, we won't have a "web.xml", just a property in the manifest pointing to the Application class. However, we will have an XML configuration file for the parent Component managing the deployed applications. For each application, setting of context parameters will be allowed in the XML config. Therefore, your application could be redeployed (as a WAR) several times without having to reconfigure it. As I don't think we can do something similar with Servlet WARs, if modifying the "web.xml" file before packaging your WAR file isn't easy for you (for example if you have to deploy to different environments/containers at the same time), then we need to explore another path :-) Note that the Servlet API appears to have had similar issues with their "contextPath" property. That was addressed in Servlet API 2.5. See: http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest. html#getContextPath() Suggested workaround: --------------------- You could provide a custom ServerServlet adapter, overriding the "init()" method to add a parameter with the full Servlet host information to your application. Currently, the application is only created on the first request, which is really annoying in your case. So, I've just fixed this limitation and released a new snapshot (see other email). Now, Restlet applications are started upon Servlet initialization and stopped upon Servlet destruction. There is also a new "getApplication()" method that you can use when overriding the default init() behavior to set the parameter based on the Servlet's context path/real path. Just remember to invoke super.init() when your done. Best regards, Jerome > -----Message d'origine----- > De : Chuck Hinson [mailto:[EMAIL PROTECTED] > Envoyé : mardi 20 février 2007 23:36 > À : [email protected] > Objet : RE: Find host info from Application > > > REST/HTTP perfectly allows multiple URIs to point to the same > resource. > > My car allows me to drive at high speeds - it doesnt mean > that I should. > > There have been numerous debates about the advisability of having > multiple URIs for the same resource. See this thread, for example, > from the REST-discuss archives: > http://tech.groups.yahoo.com/group/rest-discuss/message/7321 > > And I'll point back to "Architecture of the World Wide Web, > Volume One" > (AWWW) published by the W3C TAG (of which I belive Roy Fielding was a > member when the document was published) - "Assign distinct URIs to > distinct resources." See section 2.3.1 URI Aliases for a > discussion of > why it is bad practice to have multiple URIs for the same resource. > > Having said that, your 'customers' obviously like to do that sort of > thing, so you're going to support it. > > > > Another strategy would be to initialize your application upon first > request. > > Except that I may have a need for the information before I > ever receive > a request. My application acts as both a client and a server. As a > client, it needs to send its canonical URI to other services on the > network, and it needs to do that regardless of whether or when it > receives a request. > > --Chuck > > > -----Original Message----- > From: Jerome Louvel [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 20, 2007 4:43 PM > To: [email protected] > Subject: RE: RE: RE: RE: Find host info from Application > > > Hi Chuck, > > > The more I think about this, the more it seems that something is > > fundamentally wrong here. > :-/ > > > According to AWWW[1], "Assign distinct URIs to distinct resources." > > > > So if an application is the thing that manages a set of resources > > (i.e,. a URI space), having it attached to multiple virtual hosts > > guarantees that your resources will not have distinct URIs. > > REST/HTTP perfectly allows multiple URIs to point to the same > resource. > For example, you could have a virtual host accepting translated domain > names like www.mysite.org and www.monsite.org. Other useful cases are > when you want to support "localhost" access by IP address, > etc. This is > useful to flexible in these cases for development and pre-production. > > > I'm also wondering if the baby's being thrown out with the > bathwater > > here. Just because some people want to attach an application to > > multiple virtual hosts doesn't rule out the case the some > people will > > only ever attach an application to a single virtual host. > > Actually, the virtual hosting we support is even more flexible as we > take into account the following attributes when determining > if a request > matches a given virtual host: > - hostRef (hostDomain + hostPort + hostScheme) > - resourceRef (resourceDomain + resourcePort + resourceScheme) > - serverInfo (serverAddress + serverPort) > > As a result, we are even able to properly route requests for resources > with URIs like "urn:isbn:..." submitted via HTTP. This is > more flexible > than Apache HTTP Server's virtual hosting support, and hopefully it > doesn't compromise RESTful design. > > > Perhaps its worth revisiting the way virtual hosting is > being handled. > > > Or maybe I'm misunderstanding who is repsonsible for managing an > > application's URI space. > > The URI space is managed by both the virtual hosts and then by the > applications. If the resource URIs don't match the host URI (like for > the URN example given above), then the resource URI space is entirely > managed by the application. > > > As for using the application's context in web.xml - that's > just plain > > ugly; everytime I deploy, I have to unwrap my war so I can modify > > web.xml to change hostname and port info. > > (Deployment-specific config info just shouldn't be in web.xml) > > Hmm, that's true. > > > Oh well, for now web.xml will have to do for a temporary solution. > > Another strategy would be to initialize your application upon first > request. > You can override the "init(Request, Response)" method on your > Application class for this purpose. Just remember to check whether the > application is already started and to call super.init() when you are > done with your initialization. > > Hope this helps, > Jerome
