esear
commented
11 years ago I think this the root of the discussion we need to finalize. I think we need to identify the resource model we are looking to represent (i.e. that excel doc I sent you).
To your question above, credits seems to be an attribute (or sub-resource) of a loyalty resource called /program (maybe?) and you would add credits to a /program by submitting a POST against the resource.
OPTION 1: credits is part of the resource model POST /loyalty/program/[programID]/credits OR POST /loyalty/program/credits?programID= The body of the post could be as simple as {"credits": "1"} OR {"credits": "-5"} the number representing what we need to add to the current credit balance.
OPTION 2: credits are an attribute to a program POST /loyalty/program/[programID] body of the post: here is where my dev skills end. Would we need to provide the entire object or just changed elements? I presume would could just provide the credits attribute and the server would know to just update that value. {"credits": "1"} OR {"credits": "-5"}
We could also make the client manage the math, and have them just put what the credit total should be. This has the benefit of being idempotent. PUT /loyalty/program/[programID] body of the PUT, {"credits": "9"} - 9 representing what we need to update the total credits to.
The design seems truly representational, so that is a nice, and lends to ease of use. But I do have a couple of questions on that format. -How would be differentiate between different types of POST, GET, etc. -Would we Redesign the Noun/Verb? This might be less intuitive at times. -Or add a verb (method name) to the URL? -This is how I had done this in the past, seemed less "restfull"
Here is my example, how would we differentiate what to do on a post to Credits? How would we know what action to take here: -These three are similar and seem logical to be POST -AddCredits -CloseTransaction -CloseTransactionWith Sku