4 months ago

REST purity - 200 OK vs 201 created

Posted 4 months ago by davestewart


We have a web app (SPA) where on one of the pages, the user can edit and submit a list of items (stock codes, quantities).

This is done using a Grid component, like Google Sheets, and works great.

As the user types, we do GET requests to populate additional columns with information such as price calculations, descriptions, etc, etc.

The user can then set a name for the list, then POST the whole thing as JSON.

Additional functionality - file upload

However, the user can also upload a CSV or XLS with the codes and quantities.

We have it set up so as soon as the user selects a file it uploads transparently in the background, and the the list is populated with the result. This works very similarly to how it works when typing.


However, the developer in charge of this feature wants to change the implementation and says we must submit the name and file without any background upload, then and then redirect to the edit/:id version of the URL to see the results and continue.

Apparently, the way we are doing it now is not proper REST (he says it doesn't create a resource and so he won't return the converted results) and he is refusing to back down on the matter even though the users love it.

This results in a poor UX for the user because if they want to use a file, they HAVE to fill out the whole form, create a resource, and redirect.

Bear in mind, this is an SPA so we don't have the same constraints as a regular HTML form on the front end.


What's the deal here?

Surely returning a 200 with the results of the POST to a related endpoint would be OK?

If not, is there some way we can do this that will not offend his "pure" sensibilities?

Would appreciate some impartial input, thanks.

Please sign in or create an account to participate in this conversation.