[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RESTful XML for updates?
- From: "Scott, Christopher" <christopher.scott@fiserv.com>
- To: <xml-dev@lists.xml.org>
- Date: Thu, 5 Mar 2009 16:19:35 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]