Using one REST resource to create another

Question

In a shopping cart application, suppose I have an endpoint for an endpoint for an /product/ for products that can be bought and a /cartitem/ for items in a shopping cart. Example of GET /product/2 response

{
    "sku": "12345"
    "name":"mars bar"
}

Example of a GET /cartitem/56

{
    "quantity": 4
    "sku": "12345"
    "name":"mars bar"
}

When adding a cartitem, I will do a POST to /cartitem/ but instead of having to pass up the entire body, I'd like to able to just post a reference to the product

POST /cartitem

BODY:

{   
    "quantity": "4"
    "product":"/product/2"
}

instead of having to do:

POST /cartitem/

{
    "quantity": 4
    "sku": "12345"
    "name":"mars bar"
}

Note, I never want to have:

GET
{   
    "quantity": "4"
    "product":"/product/2"
}

Reason is because there are multiple to ways to add a cartitem, sometimes you will have a product, sometimes you want. I want the response to not have to reference a product URI, but I want the POST to be allowed to reference it to make it easier for some clients.

Is that okay?

Thanks

the best way would be to just send the id of the product not the full link. Imagine tomorrow you change your url and it will be `products` then every cart would be invalid. Just store the quantity and the ID — sheplu, Oct 02 '17 at 18:56
As your sample is far from being RESTful, I'd say do however you like. REST aims at decoupling clients from server APIs by following a certain set of recommendations/constraints. If you don't need that kind of robustness to changes simply use your own approach - but don't call it REST then — Roman Vottner, Oct 02 '17 at 20:47
@RomanVottner but exactly what part of REST is being violated? There is no statefulness being introduced. Regarding the uniform interface according to dissertation: "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. T" So can't see what's being violated there. — More Than Five, Oct 02 '17 at 23:00
Besides the given constraint given in Fieldings thesis he later explained [some of the constraints](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven), a REST API or client has to adhere to, further. I don't see the server supporting the clients on how to construct URIs or where to send requests to (HATEOAS). Admitingly you haven't included the media type of the response, though it looks like plain JSON. How does the client know the semantics of the received payload? May look like a typed resource than which is an indication for strong coupling — Roman Vottner, Oct 03 '17 at 00:50
In addition to that, the question itself can probably answered by looking up the semantics of [POST](https://tools.ietf.org/html/rfc7231#section-4.3.3) which clearly states that the request is processed `... according to the resource's own specific semantics` which means you can literally do anything with it and create a representation in the fom you desire or need. But you can also take a look at [HAL](http://stateless.co/hal_specification.html) where you can embed the content of other resources — Roman Vottner, Oct 03 '17 at 01:01
@RomanVottner I omitted hypermedia from the responses because my question was only about can you pass something like hypermedia on the POST on the way in? The question isn't about "received payload" — More Than Five, Oct 03 '17 at 06:22

score 1 · Answer 1 · answered Oct 02 '17 at 18:59

1

You should use the primary key (ID) of the product instead of a link. The end result would be the same but its cleaner and makes more sense. You would just have to implement the logic for this.

answered Oct 02 '17 at 18:59

Omar Himada

2,540
1
14
31

Why is it cleaner? Either way it is going to a server that should be able to figure out id from URL and then make database hit to get Product. – More Than Five Oct 02 '17 at 19:40
It is cleaner because having to prefix every argument with "/products/" is redundant. The primary key is always present whether its "/products/1" or "/products/125954", so why not just remove the redundant portion and keep it straight and to-the-point? Besides, using the primary key of an object as to associate one thing to another is standard practice across almost every environment and task - whether you're associating classes for an MVC project or creating a RESTful API, etc. – Omar Himada Oct 03 '17 at 12:55

Using one REST resource to create another

1 Answers1