CODEWITHSUNDEEP
restapi-design
eugene
eugene

Reputation: 41665

REST where should end point go?

Suppose there's USERS and ORDERS

for a specific user's order list

You could do

Which one is prefered and why?

Upvotes: 3

Views: 40

Answers (3)

ChatterOne
ChatterOne

Reputation: 3541

The whole point of REST is resources. You should try and map them as closely as possible to the actual requests you're going to get. I'd definitely not call it order_list because that looks like an action (you're "listing" the orders, while GET should be enough to tell you that you're getting something)

So, first of all I think you should have /users instead of /user, Then consider it as a tree structure:

  • A seller (for lack of a better name) can have multiple users
  • A user can have multiple orders
  • An order can have multiple items

So, I'd go for something like:

  • The seller can see its users with yourdomain.com/my/users
  • The details of a single user can be seen with yourdomain.com/my/users/3
  • The orders of a single user can be seen with yourdomain.com/my/users/3/orders
  • The items of a single order can be seen with yourdomain.com/my/users/3/orders/5

Upvotes: 0

Ivan Semochkin
Ivan Semochkin

Reputation: 8897

When I started to create an API, I was thinking about the same question.
Video from apigee. help me a lot.

In a nutshell when you decide to build an API, you should decide which entity is independent and which is only related to someone.
For example, if you have a specific endpoint for orders with create/update/delete operations, then it will be fine to use a second approach /order/?user=3.
In the other way, if orders have only one representation, depends on a user and they don't have any special interaction then you could first approach.

There is also nice article about best practice

Upvotes: 0

jjj
jjj

Reputation: 1154

Optional parameters tend to be easier to put in the query string.

If you want to return a 404 error when the parameter value does not correspond to an existing resource then I would tend towards a path segment parameter. e.g. /customer/232 where 232 is not a valid customer id.

If however you want to return an empty list then when the parameter is not found then query string parameters. e.g. /contacts?name=dave

If a parameter affects an entire URI structure then use a path e.g. a language parameter /en/document/foo.txt versus /document/foo.txt?language=en

If unique identifiers to be in a path rather than a query parameter.

Path is friendly for search engine/browser history/ Navigation.

Upvotes: 1

Related Questions