PUT and update object

[Nibexo]

Hi all,

I'm wondering how should look REST to such case. I have object user which has the following fields:

• username,
  
• firstName,
  
• secondName,
  
• password,
• enforcedChangePassword(true/false) - if is true user has to change password after login,
• email,
  
• status(enabled/disabled),
  
• roles

Administrator can see all fields (without password) and change all fields (without username and password).  

User can see all fields (without status, password and enforcedChangePassword) and change all fields (without status, password (for change password is special endpoint), enforcedChangePassword and roles). 

Rest method PUT said that I should send whole object even if I'm modifying one field. Whether I have to send fields which are immutable (like username or roles when I'm user not administrator)? 

[Jørn Wildt]

HTTP (not REST) defines PUT as a complete replacement of the target resource. If you want to do partial updates then look for HTTP PATCH or simply do POST.

Not all people accept the idea that PUT is complete replacement only, as you might as well do partial update with PUT too. But that is how the standard ended up. Usually I quote this one:

From: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0653.html

[Fielding]

> In the web-as-deployed, partial updates often use the PUT method.

In the Web as defined, standardized, and deployed, those partial
updates using the PUT method are not interoperable with standard
HTTP/1.x servers.  That has been known since the idea was first
brought up and has not changed since then.  We could not make
non-compatible changes to an existing method in 1996, nor 1999,
nor can we do so now in 2012.  There is no such thing as partial
updates using PUT.

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Kijana Woodard]

Fwiw, the object [resource?] you posted looks badly modeled to me.

There are too many competing concerns [too many reasons to change].

The evidence is all the "Xyz user can see these fields but not those fields" comments.

Separating concerns will go along way to cleaning up the PUT vs POST issues.

To the main point however, I agree with Jørn.

@Jørn - thanks for the quote.

[mca]

another key point is that HTTP talks about using to PUT to replace RESOURCES, not data records or business objects, etc.

my implementations often expose several resources for the same data storage record(s). many resources are actually compositions of multiple objects and/or storage records.

to repeat a valuable maxim:

"Your storage model is not your object model is not your resource model is not your representation model."

[Mike Kelly]

wrt the quote...

That's Roy Fielding who (after he posted this) pushed a change to the original wording of HTTP that attempts to remove unambiguity.

Ask yourself; if there was actually "no such thing as partial updates using PUT." why would that change have been necessary?

Also, if you look at the web as-is (not as defined) there are _plenty_ of deployed examples of partial updates using PUT and they appear to be fully interoperable with the rest of the web.

That quote should be taken with a large pinch of salt.

Cheers,

M

--

Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[Mike Kelly]

Woops, typo it was meant to say Roy "pushed a change to the original wording of HTTP that attempts to remove _ambiguity_."

[Mike Kelly]

You can just use PUT and have the client only supply the properties that it wishes to update.

It's far simpler for your clients than messing around with patch media types.

An easy to use API is probably more important to your clients than specification pedantry that brings no benefit.

Such is the real world.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Adrien Risser]

I've found JSON merge patch to be really easy to use for partial updates.

https://tools.ietf.org/html/rfc7386

[lolo]

Hi Mike,
Could you more explain:

"Your storage model is not your object model is not your resource model is not your representation model."

What is differences between storage model, object model, resource model and representation model? Can I have representation model which don't has all resource parameters? 

[mca]

yes, you get the idea.

MY DATA MODEL IS NOT MY OBJECT MODEL

first, the data model (SQL, DocStore, FileSystem) is indepdendent of the object model in the program. for example, i might store customer information (including contact info, financial profile, and order history) in a database. and i might have an object model in my code that includes a customerSummary object. this customerSummary is not a data table. it is made up of details from each of the three data tables, tho.

MY OBJECT MODEL IS NOT MY RESOURCE MODEL

my HTTP resources might take into account the *context* of the user (e.g. visitor, customer, sales rep, admin) and offer different resources for each of them that exposes select customer data. e.g. the /public/customers/ resource might show a list of customer names only with a link to see detail if security context supports that. and the /sales/customer/ resource might list each customer along with recent order history and links to contact that customer directly, update the order history, etc. and the /private/customer/ resource might list only customer information that should be seen by the logged in customer (along with pointers to order history, the ability to start a new order, make a sales inquiry, etc.  none of these resources exist in the internal programming object model -- they are, however, aggregates of a handful of internal objects.

MY RESOURCE MODEL IS NOT MY REPRESENTATION MODEL

my HTTP resources might support content-negotiation for responses. for example, my customers might be able to request their order history (/private/customer/orders/) in CSV format or the standard HTML display. the HTML version might first show summaries of each order w/ a link to details of each. But the CSV response might show all the details in a single listing (listing order lines w/ orderid to show the relationships, etc.).

the point to all this is that HTTP only has something to say about the last two elements (RESOURCE and REPRESENTATION) and when HTTP says PUT is for replacing a resource that may have no direct correlation to any single internal OBJECT or DATA-RECORD. and there might even be a case where executing a PUT on a CSV representation of a resource will include different data elements than an HTML representation of that same resource.

does that help?

mca

Mike Amundsen

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund