Page 83- How can seperate orders have the same orderId thus creating a conflict

[Orbee]

I was reading the ETag section. The example given is related to 2 consumers making coffee orders and trying to update the order at the same time.  If 2 separate orders are received for coffee by the application, I would expect the service to generate a different orderId for each order placed.  In that case when each consumer wants to check whether the state of the resource has changed they should be checking using their respective orderIds and the ETags associated with them.  Is that not the case? If so, where does the race condition apply in your example for the PUT operation?

 

[Ian Robinson]

Hi Brian

The example described here is of a single order: 2 customers trying to amend the same order. If there were 2 separate orders, we would expect 2 different order ids, but this is a single order for 2 coffees.

Kind regards

ian

On 29 January 2014 03:11, Orbee <briande...@gmail.com> wrote:

I was reading the ETag section. The example given is related to 2 consumers making coffee orders and trying to update the order at the same time.  If 2 separate orders are received for coffee by the application, I would expect the service to generate a different orderId for each order placed.  In that case when each consumer wants to check whether the state of the resource has changed they should be checking using their respective orderIds and the ETags associated with them.  Is that not the case? If so, where does the race condition apply in your example for the PUT operation?

 

--
You received this message because you are subscribed to the Google Groups "restinpractice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to restinpractic...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Davies]

Hi Ian,

Many thanks for your reply. I now understand the scenario. However, I have yet another question regarding the hypermedia controls. How does the user know how to use the payment activity for example without knowing about return types and operations within it.  i do not understand what advantage this approach has over having multiple URIs for each activity. It seems to me we are simply shifting the focus from what details  the user needs to have of the the service from one strategy to another. If one considers the payment activity, the user needs to know how to navigate the API. I might be missing something here but short of auto generating the stubs such as was explained using the WADL2Java i don't see what benefit this approach offers, other than the advantage of providing a single URI as opposed to many.

Thanks

Brian Davies.

You received this message because you are subscribed to a topic in the Google Groups "restinpractice" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/restinpractice/XpCRYHNOX44/unsubscribe.
To unsubscribe from this group and all its topics, send an email to restinpractic...@googlegroups.com.

[Jim Webber]

Hello Brian,

> Many thanks for your reply. I now understand the scenario. However, I have yet another question regarding the hypermedia controls. How does the user know how to use the payment activity for example without knowing about return types and operations within it.

As a customer you get a rel value whose semantics you know because you understand the application/restbucks+xml media type. If you don't understand that, you can't use the service.

> i do not understand what advantage this approach has over having multiple URIs for each activity.

There are multiple URIs for all the things (workflows, entities) in Restbucks, but the client doesn't need to compute them, the server does. The client need only understand the semantics of the contract (in this case just the media type but in general the media type any additional hypermedia controls layered on top).

As an aside, think how annoying/useless it would be if you had to compute the URIs when you're browsing the Web, rather than have the servers do it.

> I might be missing something here but short of auto generating the stubs such as was explained using the WADL2Java i don't see what benefit this approach offers, other than the advantage of providing a single URI as opposed to many.

This definitely isn't about auto-generating stubs, it's about having a URI for important things. The shop has a URI (http://restbucks.com), the "counter" has a URI (http://restbucks.com/orders) and each order has a URI containing URIs that reference the line items. This is as it should be on the Web: important things get named (that is, they have URIs).

Personal opinion: WADL is lame, avoid.

Jim