Cart
[Home] [By Thread] [By Date] [Recent Entries]
You might post the same questions to the 'rest-discuss' list which is more focussed on these types of issues. That said, my comments below: On Mar 9, 2009, at 10:53 AM, ext Scott, Christopher wrote: > Thanks for the responses. It seems that the consensus is that if a > resource is partially updateable, the updateable parts should be their > own resource. That seems elegant and RESTful. Thus we're left with > something like: > > <Widget> > <Id>0FAB7894C</Id> > <CreatedDate>2009-03-05</CreatedDate> > <State href="./State">INSPECTED</State> > <Color href="./Blue">Blue</Color> > <Whatsists> > <Whatsist href="./Whatsist/1002"/> > <Whatsist href="./Whatsist/1002"/> > </Whatsists> > </Widget> > > Even so, that leaves me with two questions: > > 1. Take, for instance, the State element and the Whatsists. How would > the client know if you could POST to the "State", but not PUT, and > only > GET and PUT "Whatsists"? The server would return a 405 when something > isn't allowed, but I still feel as though the client should be able to > know this information before making another request. As you mentioned yourself, the OPTIONS method would be one way. You could also use a metadata format such as WADL (or in theory WSDL 2.0) and create metadata resources linked to your data resources. A client would need to retrieve metadata before it could "know" anything about the data. I'll just note that some people do not "believe" in the need for metadata in RESTful systems. [...] > 2. It would seem that for large partially-updateable resources, this > would increase the amount of HTTP traffic over, say, a single update > document. That's true. > Furthermore, if keep-alive isn't used, then there is a > significant connection overhead. For me, however, this isn't a big > deal > because my resources aren't that huge, but this design could impact > scalability. Some sort of container POST with separated documents, as > postulated in the article linked by Peter could be an OK solution to > this. Indeed, your design will be affected by constraints, such as network latency and bandwidth. Only you can decide what the constraints worth paying attention to are, and thus, the design that will work best within those constraints. Your answers are likely at least as good as anyone else's, but Fielding's thesis [1] on the design of networked software architectures might provide a good starting point, if your domain is roughly 'the Web'. Regards, - johnk [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm > ~Chris > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
