Are the two URLs handled by the same service endpoint?

[albrikt a]

hi

Note that I haven't yet started learning any Web Service technology ( Web API book I bought requires prior knowledge of REST ), so how web services work under the hood is pretty fuzzy right now. Hence, I apologize if questions are dumb

1) 

a) If customer wants to create or update a coffee card, it needs to go to URL http://restbucks.com/order/{OrderId}/coffeecard

I assume this URL doesn't identify a coffee card resource, but instead identifies a service endpoint which creates/updates a coffee card? 

b) If my assumption under a) is correct, then I assume requests to the following two URLs are handled by the same service endpoint:

http://restbucks.com/order/1/coffeecard

http://restbucks.com/order/2/coffeecard

?

2) If consumer wants to pay for the order using a coffee card, it needs to post its card to the coffee-card-payment URL http://restbucks.com/payment/coffee-card/{OrderId}.  

a) I assume this URL identifies a coffee-card payment resource?

b) Is payment resource  still created ( behind the scenes ) when we pay for order using a coffee card?

Thank you

[Jim Webber]

Hello!

> a) If customer wants to create or update a coffee card, it needs to go to URL http://restbucks.com/order/{OrderId}/coffeecard
>
> I assume this URL doesn't identify a coffee card resource, but instead identifies a service endpoint which creates/updates a coffee card?

I can totally empathise with that point of view. You're right that the link in the order is like this:

<dap:link rel=′′http://relations.restbucks.com/coffee-card′′

uri=′′http://restbucks.com/order/1234/coffeecard′′

mediaType=′′application/vnd.restbucks+xml′′/>

But when the coffee card representation is returned (200 OK) the self link is: http://restbucks.com/coffeecard/4456afd23

In retrospect it might have been sensible to use the second URI in both places. However in the note following the example it states:

"there is no correlation between the coffee card and a specific order, despite the format of the UrI in example 5-13. remember, UrIs are opaque to consumers. In this case, the link contains information that the restbucks ordering service uses when updating the count of endorsements in the coffee card."

Remember, we're not invited to parse the URIs, only understand and act on the links.

> 2) If consumer wants to pay for the order using a coffee card, it needs to post its card to the coffee-card-payment URL http://restbucks.com/payment/coffee-card/{OrderId}.
>
> a) I assume this URL identifies a coffee-card payment resource?

It identifies the payment for that order as the link advertises.

> b) Is payment resource still created ( behind the scenes ) when we pay for order using a coffee card?

Yes, in the implementation I believe it is. Go to http://restinpractice.com and grab to code for Chapter 5.

Hope that helps,

Jim

[albrikt a]

hi

Please correct me if I'm wrong:

1) 

> I can totally empathise with that point of view. You're right that the link in the order is like this: 
>

> <dap:link ...  uri=′′http://restbucks.com/order/1234/coffeecard′′ ... ′/> 

>
> But when the coffee card representation is returned (200 OK) the self link is: http://restbucks.com/coffeecard/4456afd23 
>
> In retrospect it might have been sensible to use the second URI in both places. 

> ...

> Remember, we're not invited to parse the URIs, only understand and act on the links.

If I understand you correctly, both http://restbucks.com/order/1234/coffeecard and http://restbucks.com/coffeecard/4456afd23 identify the same coffee card resource?

2)

>> If consumer wants to pay for the order using a coffee card, it needs to post its card to the coffee-card-payment URL 

>> http://restbucks.com/payment/coffee-card/{OrderId}.   

>> 
>> a) I assume this URL identifies a coffee-card payment resource? 
>
> It identifies the payment for that order as the link advertises. 

So there is no coffee-card payment resource created? Instead both http://restbucks.com/payment/coffee-card/1234 and http://restbucks.com/payment/1234 identify the same "regular" payment resource?

> Go to http://restinpractice.com and grab to code for Chapter 5.

I don't know WCF nor JAX-RS :(

and thank you for helping me

[Jim Webber]

> If I understand you correctly, both http://restbucks.com/order/1234/coffeecard and http://restbucks.com/coffeecard/4456afd23 identify the same coffee card resource?

They might do. Or not. It might be that operating on http://restbucks.com/order/1234/coffeecard simply parameterises the resource that is subsequently made available at http://restbucks.com/coffeecard/4456afd23.

> So there is no coffee-card payment resource created? Instead both http://restbucks.com/payment/coffee-card/1234 and http://restbucks.com/payment/1234 identify the same "regular" payment resource?

Under the covers that might or might not be a sane implementation decision. On the web though, they're both just payments.

> > Go to http://restinpractice.com and grab to code for Chapter 5.
>
> I don't know WCF nor JAX-RS :(
>
> and thank you for helping me

Oh, not to worry. Keep posting here and we'll translate the Java/.NET into English :-)

Jim

[albrikt a]

hi

Just one more question

>> If I understand you correctly, both http://restbucks.com/order/1234/coffeecard and http://restbucks.com/coffeecard/4456afd23 identify the same coffee

>> card resource? 
>

> They might do. Or not.  It might be that operating on http://restbucks.com/order/1234/coffeecard simply parameterises the resource that is

> subsequently made available at http://restbucks.com/coffeecard/4456afd23. 

>

What exactly do you mean by "it parameterises the resource"?

much thanx

[Jim Webber]

> What exactly do you mean by "it parameterises the resource"?

I mean when you GET http://restbucks.com/order/1234/coffeecard it might have the idempotent side-effect of adding 1 purchase to the coffee card at http://restbucks.com/coffeecard/4456afd23.

This isn't really a REST thing, but an implementation choice.

Jim

[albrikt a]

thank you for your time and help

cheers