Independently updatable parts of a resource – how to?

[albrikt a]

hi

1) 

Pg. 81:

"If two parts of a resource are independently updatable, they should be separately addressable resources."

a) So if order resource would allow <milk> state to be independently updatable from other parts of order resource, then we could (should?) create a separate resource containing just <milk> state?

b) If my assumption in a) is correct, then we'd have two resources R1 and R2, where R2 would only contain <milk> state, while R1 would contain all other state. But should R1 also contain <milk> state?

c) I assume even if R1 also contains <milk> state, consumers shouldn't be able to also set <milk> state when updating R1?

d) Assuming R1 shouldn't contain <milk> state, then how do we indicate to consumers that R1 and R2 combined represent order?

2) At https://groups.google.com/forum/#!topic/restinpractice/hE3wQ2U9UaQ Jim Webber implied that it's still REST if one uses the following two links, each updating different parts of coffee order:

<dap:link rel="http://relations.restbucks.com/addition" ... uri="http://restbucks.com.order/1/additions" />

<dap:link rel="http://relations.restbucks.com/cupsize" ... uri="http://restbucks.com.order/1/cups" />

a) I assume http://restbucks.com.order/1/additions and http://restbucks.com.order/1/cups identify two different resources, one representing addition state and other cupsize state?

b) If my assumption in a) is correct, is then order represented  

• As a combination of three resources: addition resource, cupsize resource and another resource R3 ( which contains the rest of order state ) or
• does R3 also contain states for addition and cupsize and as such on its own already represents a complete order?

thank you

[Peter Oostwoud-Sibiryak]

Hi albrikt,

Interesting questions! 

1) In addition to your assumptions: How would this compare to the patch verb? This allows to even update a single property of a resource. So all properties should be resources?

In my opinion you should always consider your use cases. I'm currently testing a separate resource and state (representation) layer that forms the communication between the user interface and business logic. Usually the business logic was formed to the use cases, however now I'm considering to abstract the business logic away between the resource logic that represents the use cases.

Btw, when it comes to state: take a look at the book "Designing Evolvable Web APIs with ASP.NET". Their example separates the management (CRUD) from the processing (state). In my opinion a smart approach.

2) Your assumption is correct. These are two different resources in context of order 1. In the example an order has a fixed set of elements. However in my opinion this is just sort of a fixed set of lines. I would read this in the same way as /order/1/line/x, only now the number of lines is variable. 

As stated in 1: Check the patch verb and stay close to your use cases. The latter always gives the answer.

As a final comment: Stay pragmatic. If your building a business system, get as restful as possible, but let the business prevail at anytime.

Hope this helps a little!

Cheers,

Peter

Op dinsdag 1 juli 2014 21:17:33 UTC+2 schreef albrikt a: