Are the two URLs handled by the same service endpoint?

14 views
Skip to first unread message

albrikt a

unread,
Jun 23, 2014, 1:57:17 PM6/23/14
to restinp...@googlegroups.com
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:


?

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

unread,
Jun 23, 2014, 3:36:48 PM6/23/14
to restinp...@googlegroups.com
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

unread,
Jun 23, 2014, 4:23:33 PM6/23/14
to restinp...@googlegroups.com
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 
>> 
>> 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

unread,
Jun 24, 2014, 3:42:42 PM6/24/14
to restinp...@googlegroups.com
> 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

unread,
Jun 24, 2014, 4:19:27 PM6/24/14
to restinp...@googlegroups.com
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

unread,
Jun 25, 2014, 3:59:08 AM6/25/14
to restinp...@googlegroups.com
> 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

unread,
Jun 25, 2014, 8:26:10 AM6/25/14
to restinp...@googlegroups.com
thank you for your time and help

cheers
Reply all
Reply to author
Forward
0 new messages