Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


[xml-dev] RESTful XML for updates?

From: "Scott, Christopher" <christopher.scott@------.--->
To: <xml-dev@-----.---.--->
Date: 3/5/2009 9:19:00 PM
Hello all,

	I'm putting together a RESTful webservice and I wanted to get
some input about how one would design XML resource representations.  The
question has to deal with designing the resource with updates in mind.
I've googled for examples but most articles outline what a resource
should look like, but not how it should be updated.

I would like to be able to update a representation without having to PUT
the entire resource representation back to the server.  For example,
consider a simple resource which resides at a URL /Widget/001

<Widget>
  <Id>0FAB7894C</Id>
  <CreatedDate>2009-03-05</CreatedDate>
  <State>INSPECTED</State>
  <Color>Blue</Color>
  <Whatsists>
    <Whatsist href="/Whatsist/1002"/>
    <Whatsist href="/Whatsist/1002"/>
  </Whatsists>
</Widget>

I'd like the client to be able to change the color or state of this
widget to, say REJECTED, but not be able to change the id, or the
CreatedDate.  I can perform that validation on the server side with no
problem, but it seems that that wasn't a terribly RESTful solution.  The
client should be able to discover which resources are updateable.
Besides, we already have confusion with an existing interface where one
can't tell which fields are updateable.

I'm currently leaning towards making an attribute in another namespace,
say

...
<State foo:updateId="1234">INSPECTED</State>
...

Then the client would absolutely know which fields are updateable and be
able to update those fields without having to replicate the entire
resource.  The client would be able to post (only):

<State foo:updateId="1234">REJECTED</State>

To /Widget/001 and update the resource.  This could apply also to
complexTypes as well as the simpleType shown here.

So my questions:

1. Is there a simpler way to give client the ability to update resources
without having to upload the entire representation?
2. Is there a simpler way to indicate which fields are updateble?
3. If I were to define an XML schema for resources, what would be the
best way to simply say that any element defined can have a foo:updateId?
I'd rather not have to do it explicitly for each declaration.
4. Am I even asking these questions in a RESTFul way?

Thanks in advance for your help,

~Chris
 
Christopher Scott
Senior Programmer/Analyst
Loan Fulfillment Solutions
Fiserv

_______________________________________________________________________

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



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent