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
>


_______________________________________________________________________

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