I am aware of two primary approaches to deal with this problem: 1) Directory-style discovery. By this, I mean that there is a resource that contains references to other resources, that is accessible and is one of the known URIs to all clients. For example, a "folder" resource may contain references to the other files and folders that it contains, and a client could be built to navigate around the structure to discover resources in which it is interested.
2) Search-style discovery. If you are interested only in certain types of resources being discoverable, you can write a resource that accepts some search criteria and performs a search against your data sources. Typically, the results of such a search would be provided back as references to the resources that represent those entities that have hit the criteria. Those are probably the most straightforward ways to do it. But, again, this isn't really about Restlet, is it? :) On Tue, Apr 7, 2009 at 2:27 AM, <webp...@tigris.org> wrote: > hi, some day ago i posted a a problem. > > "Hi i'm an italian student and i have to plan a restful architecture using > RESTLET. > > The architecture have to implement a B2B message exchange in xml format > powered by GS1 XML. > > -My problem is to understand how makes the client thet have to get or post > a resource to know resource's location and therefore the final url to use in > the GET or POST HTTP messages to refer to the correct locations." > > Here your responce > > Stephen Groucutt said: > > "Do you mean, how can a client know what URIs to use when performing > service > operations? > It really doesn't have anything to do with Restlet in particular, and I > could be wrong here, but I think this is a still-evolving aspect of REST. > For a while, WADL seemed to be gaining some momentum, but there are some > arguments against using it, the most notable of which is that we don't > really want to repeat the mistakes of WSDL (the "give me a WSDL and I'll > auto-generate my client code" mentality goes against some of the basic > principles of REST, primarily flexibility but probably other stuff too). If > you google around on WADL, you'll see what people have to say. > > The key, though, is that once you know where to start (a base URI to use > when beginning your operations), a system that obeys REST correctly will > make it easy for a client to operate after that. For example, let's say you > have a generic object factory kind of resource, at > https://server/app/object. > That's all your client should need to know to get started. You'll POST to > this resource, to create a new resource (owing to REST's adherence to the > HTTP verbs, you know what to use to do create operations without any > further > guidance). If it succeeds, a 200 OK response comes back, along with the > location of your new object in the header of the response. The client can > pull the URI of the new object back (e.g. https://server/app/object/12), > and > do new operations with it - GET to see it, PUT to update it, DELETE to get > rid of it. > I guess this is a long way to say "I don't know", but I also think that in > a > proper REST design, it probably doesn't much matter. :) In my opinion, you > can either codify the endpoints formally, as in a WADL, or you can > informally simply agree on your starting point URIs, code them into your > clients, and go from there." > > and Rob Heittman said: > > "Excellent summary, Stephen! Requiring a descriptor (in any format) to find > a service URI often just moves the problem -- making the next question > "what > is the best URI to publish the descriptor?" > Still, it's needful to describe REST APIs, and this often seems > unreasonably > hard to do. For me, anyway. > > Someday I'd like to attack a Restlet-specific application descriptor > mechanism that is both machine and human readable ... sort of an extended > Javadoc for Restlet ... I think the Resource refactoring might be one key > to > doing this. Ideally the descriptor would work two ways -- you could export > it from a Restlet server application, and then feed it to a code generator > to make a Restlet client skeleton. We'd also need some way of interrogating > the "plumbing" of an application -- what patterns reach what targets. > Anyway, fun to think about." > ------------------------------------------- > BUT > > "what is the best URI to publish the descriptor?" is not a problem for me. > In my application all client may know this URI. The problem is that each > side of architecture have a client and a server restlet and in a server can > exist resources PUTted by itself (if it's possible to do) > and the client on the other side can accede with GET operations. This > client know the URI's of the resource PUTted by itself but don't know the > URI's of other resources. Each client can know and refer to a standard URI > for the descriptor. > > Can you help me and is it realizable????????? > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1572200 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1576406
