
On Tue, 2009-07-07 at 22:52 +0200, Johan Tibell wrote:
On Tue, Jul 7, 2009 at 10:00 PM, Thomas DuBuisson
wrote: > I now realise we need a bit more :-) > > So the issue is that we'd like to be able to specify a server by a > single URL and be able to find everything else relative to that. Ideally > we would do that by some discovery mechanism rather than hard coding > relative URLs into the clients, but in the mean time... >From what you've said my imagination makes me think of a page at $URL/jumptable that gives a list of hard coded services and their location on the server. For example, $URL/jumptable might return:
To be RESTfull this should just be $URL to avoid forcing servers to have a resource called jumptable.
What do real REST designs really do in this kind of situation? For the parts of sites intended to be consumed by humans that's easy, you use index.html and that provides links humans can choose to follow. For sites where automated and somewhat-coupled clients (ie not totally generic clients like caches, web spiders etc) are expecting certain services (it is that expectation that is the coupling), how do they discover the urls for the services they are (or might be) expecting? Do people really concoct little text or xml files giving name -> url mappings? Is there some common standard format for doing that? Duncan