0

Let say I have and Order resource. In order to get the resource I want I would do something like this:

GET /orders/{someId}

The question is what do I do when there are different kinds of gets. For example a GET to edit the order or a GET to review the order. Normally you would just use the orders/{someId} for both, but in this case I need to do some different business logic for each (some auditing).

Perhaps I could do something like this:

GET /orders/{someId}?type=review

But that seems wrong. Thoughts?

testing123
  • 10,987
  • 10
  • 42
  • 59
  • There seems to be a lot of good advice here http://stackoverflow.com/questions/4024271/rest-api-best-practices-where-to-put-parameters – Eric Woodruff Jan 23 '14 at 22:43
  • Why does it seem wrong? I see nothing wrong with it. – Darrel Miller Jan 24 '14 at 05:25
  • 'a GET to edit the order or a GET to review the order' What do you mean by that? `GET` returns a represenation of the resource, it dos not alter it. –  Jan 24 '14 at 09:49
  • Correct, a GET does not modify the order. 'a GET to edit' refers to getting the order for edit purposes, not actually editing the order. That would be a PUT (most of the time). – testing123 Jan 24 '14 at 17:49
  • @DarrelMiller I just wanted to make sure it made sense. It seemed wrong because it seemed more like a verb than a noun to me. Like flopo mention 'GET /orders/{someId}/action', I thought everything was suppose to be a noun, not an action. But like you commented, its not an action the review and the edit can be looked at like resources. What would you do if there was a case where you wanted to cancel an order. My first thought would be PUT /orders/{id}/cancelRequest? – testing123 Jan 24 '14 at 17:55
  • Actually maybe it would be PUT /orders/{id} with a body of {cancel: true}. Thoughts? – testing123 Jan 24 '14 at 18:03
  • @testing123 You can't use PUT like that because PUT requires complete replacement semantics. Ask a new question if you want to know the variety of ways you can do a "cancel". – Darrel Miller Jan 24 '14 at 18:09
  • What you mean by "getting to edit" or "getting to review"? This means the state is locked somehow until the response is submitted? If that's the case, you're dealing with another completely separated resource. – Pedro Werneck Jan 24 '14 at 22:54

2 Answers2

0
GET /orders/{someId}/action

For your needs

GET /orders/{someId}/edit
GET /orders/{someId}/review

GET should not modify the item, so I assume this URLs are just for load the resource, not for modify it.... plz clarify this

dbermudez
  • 562
  • 3
  • 9
  • I do not modify the resource, I only add some audit information as to whether they are requesting the resource in order to edit it later or just review the resource. As for your suggestion, thank you. You would treat edit and review as separate resources? That seems strange to me (not that the type request parameter is any better). – testing123 Jan 23 '14 at 23:31
  • @testing123 Yes your "edit" representation and "review" representation are different resources. Whether you use path segment or a query parameter makes very little difference. – Darrel Miller Jan 24 '14 at 05:27
  • @flopo I disagree with the idea of putting an action on the url because REST is all about urls are resources not actions (verbs), but I guess its just in the way you look at it. Like Darrel Miller said, they could be seen as resources. – testing123 Jan 24 '14 at 17:58
0

You can use different HTTP methods (as a verb), depending on the action that is taking place. This will allow you to keep the path clean and simple.

Examples:

GET /orders/{someId}
PUT /orders/{someId}
POST /orders/{someId}
DELETE /orders/{someId}

GET is used to retrieve, PUT to update, POST to create, and DELETE to remove the resource. This follows basic CRUD (create, read, update, delete). If you need to add any additional filters/parameters, use query parameters.

Michael Russo
  • 578
  • 3
  • 7
  • Equating HTTP methods to CRUD will make it particularly difficult to do anything other than CRUD with your REST api. The HTTP methods are far more flexible than that. – Darrel Miller Jan 24 '14 at 05:26
  • I'm not saying to limit use to these 4 HTTP methods. However, with REST, this is usually how they equate. I wanted to give an example of how to design with that in mind. Of course the methods can be used for many different types of requests (RESTful or not) if needed for flexibility. – Michael Russo Jan 24 '14 at 16:46
  • The idea that REST maps HTTP methods to CRUD is probably one of the main sources of confusion about what REST is. I recommend reading this answer to clarify that: http://stackoverflow.com/questions/19843480/s3-rest-api-and-post-method/19844272#19844272 – Pedro Werneck Jan 24 '14 at 22:52