2

For a simple example, I'll use tires and cars. I intend to execute a PUT to increase the price of a tire. The UI also contains cars that use the tires being updated, therefore requiring a price update of their own.

Is it appropriate for the original PUT request to contain car pricing in its response? If not, how is this typically solved?

scoots
  • 715
  • 4
  • 16

1 Answers1

2

A PUT to update a /tire price should absolutely not return details of how it updated a different resource like a /car. Doing so would co-mingle the two entities and make your resource representations overly complex. It would also make "atomic" updates of individual resources difficult for clients.

The PUT response should only tell you whether or not the update succeeded on the /tire resource, and perhaps provide the new representation of the tire in the response content. Once the PUT call to the tire has returned, the client (your UI) can then GET the /car once more and it will see a new price for the overall car that takes into account the new tire cost.

Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
  • I was thinking this was possibly the answer most would agree to. So, multiple trips to the server? And, doesn't this mean all relationships have to be known on the frontend too (assuming the logic is otherwise tasked to the server)? Otherwise, how would you know which cars to GET? Thanks! – scoots Oct 15 '13 at 12:06
  • 1
    The UI must understand the resource relationships and be responsible for knowing which things to re-GET after making an update. REST doesn't mean that clients become automatons, it just helps to create a clean, flexible interaction between client and server. – Brian Kelly Oct 15 '13 at 12:53
  • On the other hand, if you are using an envelop format that provides for sideloaded data (eg the one consumed by ember-data), then you can send: optimizing # of trips is exactly what sideloaded data is for. Clients (which know where the primary response is) can ignore the rest of the response if they want to. – shaunc Dec 31 '14 at 09:39