0

I have a situation : Category - Master data with different types. Order - Has a reference to Category. It is a one-to-one mapping from Order to Category. Order table has a foreign key column to Category. Now api to get Orders

/users/orders

Will the return type as

{ "name: "abc", "categoryId" : 23 }

will be fine or should we return the json as

{ "name: "abc", "category" : "CAT-A" }

We also have a create/update Order use case with client knowing the category. We need a api to post new Order with a Category. Should it be something like this?

1. post /api/orders { "categoryId" : 23, ....}

Or something like this?

2. post /api/orders/category/23/order
DAIRAV
  • 723
  • 1
  • 9
  • 31
Santosh
  • 1,849
  • 4
  • 19
  • 31

1 Answers1

0

first, use identifiers (or links!):

{ "name: "abc", "categoryId" : 23 }

or

{ "name: "abc", "category" : "/api/categories/23" }

not names (because those could change from time to time)

{ "name: "abc", "category" : "CAT-A" }

For the posting of orders I would suggest to use 

post /api/orders { "categoryId" : 23, ....}

just because you are adding an order on the order resource. The order should already have a category referenced (or linked!).

This approach 

post /api/orders/category/23/order

would also be okay. But the client would need to build an url with information that is already contained in the request body, so things only got a little more complicated (what if the categories in url and request body are not the same? What if the category in the request body is missing? Is the request still valid in this case?)

sschrass
  • 7,014
  • 6
  • 43
  • 62
  • Thanks for you suggestions. I agree with you that it is okay to return the caetgoryId as part of GET. Post can go with passing categoryId instead of url approach. – Santosh Jul 31 '18 at 11:23
  • Also one more question came to me, here we are using the database PK ids of foreign key tables, like categoryId in Order resource. I see many of them use it this way and some complaining not to use database PK. Just wanted to understand the debate on this. – Santosh Jul 31 '18 at 11:25
  • This would be another question, but I personally have no issues with using PKs as Id. One thing with this approach could be in an environment with multiple instances of the same service, hence consistency – sschrass Jul 31 '18 at 11:40
  • Can you slightly elaborate on the multiple instance environment? Our micro-service can go into multiple instance still talking to the same database instance. – Santosh Jul 31 '18 at 11:50
  • That is not necessarily a good thing. Imagine that you can outscale the database. Then you would need a replica and connect the new service instances to it. Now you have two instances generating Ids, what can lead to collisions (random id strategy could help here). – sschrass Jul 31 '18 at 11:53
  • correct. in that case, it would be neater to use a category code in the table and not relying on the PK id or the description. So we have a GET /categories api which lists the categories before Order creation. There we can think of returning the categoryCode and Desc. In POST /Orders, expect the categoryCode to come instead of PK. Does that makes sense? – Santosh Jul 31 '18 at 12:08
  • Does it makes sense on the last comment? – Santosh Aug 01 '18 at 14:40
  • I would use a urn https://en.m.wikipedia.org/wiki/Uniform_Resource_Name. – sschrass Aug 01 '18 at 15:53