1

To simplify I'll say I'm using a list containing an array of Movies, and Movies.

Problem

I have two options to update both the note in the list, and the global note of the Movie.

Single Calls

POST www.example.com/api/lists/:id/ // Creates a new movie entry in the list, updates Movie's note

PUT www.example.com/api/lists/:id/movies/:movieId // Updates entry, updates the note in Movie 

DELETE www.example.com/api/lists/:id/movies/:movieId // Delete the entry, remove the note from Movie

Multiple Calls

POST www.example.com/api/lists/:id // Create a new list
+
PUT www.example.com/api/movies/:id // Updates the note (total =+ note, nbNotes++)


PUT www.example.com/api/lists/:id/movies/:movieId // Updates the Movie's note in the list
+
PUT www.example.com/api/movies/:id // Updates the Movie's notes (total =+ (new-old))

DELETE www.example.com/api/lists/:id/movies/:movieId // Remove the entry
+
PUT www.example.com/api/movies/:id // Updates the Movie's notes (total =- note, nbNotes--)

I would tend to use the Single Calls but have no idea if modifying another ressource is correct. (Considering that the Movie's note will probably never be modified by its PUT api anywhere else)

I tried to take into account other StackExchange's answers but they seem more focused on the retrieval of information in the frontend whereas mine is more focused on updating data.

It feels like the Single Calls introduced some concurrency problems on implementation (or I coded it very poorly) as sometimes the note updates negatively (as an update with note: null, decreases the total note because an entry in a list can not have a note)

1

I would go with single calls. They are perfectly reasonable because a Note should not exist without a Movie. They are closely related, being the Movie the parent in that relation.

It will perform better, because the client are making fewer calls to the API, and you won't have to handle side effects like trying to add a note to a movie that just failed to be created

Despite that, you should redesign your URIs to better reflect the resources they are dealing with. For example:

POST www.example.com/api/lists/:id/ // Creates a new movie entry in the list, updates Movie's note

The URI above should be redesigned as the one below to reflect that you are adding a Movie inside the List with the provided id:

POST www.example.com/api/lists/:id/movies

You can find details on resource naming here.

Of course, you may want to separate updating movie's info, like genre, description, etc; and updating its note. If so, you can keep a different URI for this specific task. Like:

PUT www.example.com/api/movies/:id/notes
3
  • It does indeed make sense; to me at least; to use single calls. It would feel weird to use /lists/:id/movies since it's more of a MovieEntry with additional informations such as the date you added the entry, its note, status. Updating a Movie's note through an API would be weird in my case. The server modifies everything. I think I'll stay without this API (until needed) Jan 5 at 21:24
  • You can call it MovieEntry if you will, but its presence gives meaning to the URI. Any developer familiar with REST sees POST /lists/1/movie-entries and automatically deduce that it means adds a movie entry to the list with id = 1. From the URI POST /lists/1 is not possible to know that it adds movie entries unless they read the code that handles that route
    – Caconde
    Jan 6 at 1:42
  • Makes sense, thanks Jan 6 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.