Why is coffee card created via GET request and not via POST request?

albrikt a

unread,

Jun 23, 2014, 1:56:26 PM6/23/14

to restinp...@googlegroups.com

hi

Pg. 122:

Customers who do understand the semantics of the http://relations.restbucks.com/coffee-card relation but who don’t already have a coffee card can issue a simple GET request to the URI identified by the coffee-card link.

GET requests shouldn't have any server-side side effects for which the client could be held responsible.

a) If coffee card is created due to receiving a GET request, couldn't we argue that this GET request has a server side-effect for which client is held responsible? If so, why is coffee card created via GET request and not via POST request?

Thank you

Mitch Trainham

unread,

Apr 8, 2020, 3:27:39 PM4/8/20

to restinpractice

I had the exact same question. It is beyond me why a book trying to explain REST would invent examples like this, where it is so painstakingly obvious that it either violates REST or at the very least deserves an explanation, and they NEVER address it. It's mind boggling, and this question being 6 years old and remaining still unanswered shows how frustrating it is to have something not explained in an example, with no way to get an explanation

Chris Margraff

unread,

Apr 8, 2020, 4:10:13 PM4/8/20

to restinp...@googlegroups.com

Yes, according to the HTTP specification a GET request should not have any server-side effects, REST is a contract between the client and the service. If the service chooses to do something unrelated to servicing the GET, it does not violate REST. It is incredibly common to write logs, for instance, in processing any request. In this case, the service has created a relationship with the client, effectively establishing a cache or other resources that the client can draw upon in other calls.

Exactly how the service authorizes the client to access the card (ie – client credentials) is out of scope for pure REST. And, returning a 5XX error on a GET request because the card record could not be written – that is a technical violation of the contract, but it happens all the time.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/restinpractice/37d1d280-9254-4ad4-8b73-e5302b0a1aa2%40googlegroups.com.

Mitch Trainham

unread,

Apr 8, 2020, 4:23:38 PM4/8/20

to restinpractice

If the service chooses to do something unrelated to servicing the GET, it does not violate REST. It is incredibly common to write logs, for instance, in processing any request.

I understand that, logs are something that is outside of the scope of the client-server interaction, and it's something the client knows nothing about. However, in this case, the server is creating an instance of a card, which is not only within the scope of the actual application between client and server, but it should require the client to express intent that they actually want a card created, which makes the GET request to a card violate the REST principle in which a client should be able to trust that GET requests don't have side effects.

In this case, the service has created a relationship with the client, effectively establishing a cache or other resources that the client can draw upon in other calls.

See it's this kind of logic that is the reason REST is so hard to grasp. We are supposed to see "remembering client specific details from previous requests, and storing session information" as a violation of REST, as well as server side effects within the scope of client responsibility on GET requests as a violation, oh but then we bypass this by using the word "cache". I can't even begin to describe how confusing your sentence is on so many levels. This is not a cache. It is quite literally creating and saving an entity that is linked to the client, in which the client should control intent to create. It is the literal and most unambiguous example of what a POST should be that I have ever seen. Which means it forces you to try to come up with confusing abstractions to defend it.

Exactly how the service authorizes the client to access the card (ie – client credentials) is out of scope for pure REST. And, returning a 5XX error on a GET request because the card record could not be written

This isn't about how the service authorizes the client to access the card. This about how the card gets created in the first place. Obvious is an understatement to describe how there should clearly be POST to create a card before the card is used. You can't authorize a client to use a non-existent card.

To unsubscribe from this group and stop receiving emails from it, send an email to restinp...@googlegroups.com.

Reply all

Reply to author

Forward