0

I have designed some API which have some nested resources and I am wondering how to reduce the number of POSTS when I am creating some records.

for example, I have the following resources:

/orders/

and

/orders/{order_id}/products/

at the moment I need to run two POST separately if I need to create a new order or a new order's product but I would like to reduce the time for this and run only one POST. Is this possible? is there any documentation I can read about this?

Thank you

MeV
  • 3,761
  • 11
  • 45
  • 78
  • I think I have found my answer here: http://stackoverflow.com/questions/14275257/rest-creating-nested-resources-with-single-post# – MeV Aug 24 '15 at 15:57

1 Answers1

0

Although you might have found your answer in an other thread there is still some issue regarding your endpoint design.

The first intuition that your endpoint give is that product resource could exist in several place.

./orders/{order_id}/products/{prod_id}

./products/{prod_id}

The question you should ask yourself is: Do you really want to refer to product? Can product be leaving outside of any orders?

Having a resource sitting in 2 different place might not be that great as you are managing 2 different endpoint with similar behavior. Keeping consistency between both endpoint is not that easy.

My 2 cent is to avoid the term product as it can be confused with a single instance of a product. For example if you sell a toothbrush branded AAA, sku 1234 an order is not compose by this product but by one off the item that you have in stock. The item is "instance" of the toothbrush branded AAA, sku 1234.

As I understand your question you are not really referring to a product but more to a stock-item which should be a unique id.

The resource stock-item if you decide to have one should exist prior to the order. I guess the customer is not adding item to your stock and at the same time purchasing this item.

In conclusion I think that you are not creating the stock-item resource at all when creating orders but just making a reference to it.

mathk
  • 7,973
  • 6
  • 45
  • 74
  • I'd expect `/product/{prodId}` to be the resource for the product before it's been added to an order, while `/orders/{orderId}/products/{prodId}` would be the end point for the specific instance of the product that has been added to the order. The more specific resource would likely only allow PUT or DELETE operations. You are either adding or removing a reference to the product on the order. However, `/products/{prodId}` would allow GET and PUT operations because it allows you to get or replace the product at the given resource. – crush Aug 24 '15 at 17:25
  • Why not. But again for a client perspective it is not obvious what is what. REST aims to be self explainatory. – mathk Aug 24 '15 at 19:10
  • I think it would be fairly obvious, actually. One is clearly associated with an order while the other is not. If you think these need explicitly different names, then that's your prerogative, but I don't think REST mandates what you've put forth here. – crush Aug 24 '15 at 23:25
  • Suppose that you are speaking with other member of your team on the product. which one are you referring too? There would always be a chance of ambiguity. REST may not mandate you to have different term. But REST or not REST it is always a good practice to have clear distinctive term for different meaning. – mathk Aug 25 '15 at 09:44