> 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
