Single page apps and backend APIs

Question

When creating single page apps that communicate with a backend API via ajax, what is common (best?) practice regarding updating different server side database objects as a result of one client side action? For example let's say I delete something on the client which in turn results in needing to update several other items.

Perhaps we have an app that simulates people standing in a line. Each person has a position in the line. The user has the ability to delete a person from the line which results in two actions. First, delete the person from the database. Second, update the remaining people in the database to reflect their new position in the line. (This is a simple illustration, but there may also be additional database updates required to other, non person db tables).

Should the above be done in two separate ajax requests? First send the DELETE request and if the server replies with a success message, then send a PATCH request to update the remaining people positions. Or should both of those be combined into a single ajax call?

The reason I ask is because doing two separate requests would be more RESTful from the API perspective. ie: Send a DELETE request for a single object, get a success reply on the client, then send a PATCH request for multiple objects. The URLs for those would conform to typical RESTful structures.

However if you combine those requests into one it means you have to have an API endpoint which certainly is not RESTful by deleting and patching multiple items in one call. It would also not use a typical URL structure. But you end up with only one call to the server and one response confirming that everything required has been done.

So my question is, when creating SPAs with fairly complex interactions with respect to creating / deleting / updating multiple objects at once, should we still try to be RESTful in the way that the API is created and used or do we create API endpoints that do exactly what is needed in a single server call?

Answer 1

Short asnwer: Do it in the backend.

In practice, it's strategically smarter to perform all operations — that in sum form a transaction — in a backend service:

• Backends and their API endpoints usually represent some kind of portal into the data model. Speaking simple the API often is a tool to read and write from/into a database. Usually in the backend, e.g. in a language like Node, Ruby, Go, Java etc., you have control over things that might go wrong. One of your operations might fail and you want to make sure the data model stays consistent by rolling back / reverting your previous operations. That's very hard from the frontend. The user might just close the browser or disconnect from the internet during two requests and there is no reliable way of detection that.
• You might add another frontend, for example an iOS app in addition to the existing web app. Of course you want to consume the same API and reduce redundant code.

I made the experience that seeing a frontend as a "dumb" consumer of a "smart" backend helps maintaining large frontend codebases that are subject of frequent changes.

Answer 2

Your business logic should be done in the backend. What you're describing will involve more than one HTTP request, which can impact performance. Acknowledging the number of HTTP requests is crucial for Single Page Applications.