I have three seperate fields and all three are unrelated to each other but part of the same collection (Tables for SQL folks).

Now, what I'm getting stuck at is, should I allow end-users to make one big PUT request to update the data in those fields or should I have the end-user send multiple PUT request. One thing to note is that it's not mandatory that all the three fields should be updated at the one time. End-User can use to update 1 or 2 or 3 fields at one time.

Right now, I have a single PUT endpoint for all three fields. If I should go with multiple PUT request option, should I also create multiple POST endpoints for uploading the data to the server?

Right now, this is how a request looks

> PUT /id
        "type": "choice",
        "key": "choice key",
        "data": "choice data"

So this is how I'm thinking an example single PUT request will look like

> PUT /id
        "type": ["choice", "play", "extra"],
        "key": {
            "choice": "choice keys",
            "play": "play keys",
            "extra": "extra keys"
        "data": {
            "choice": "choice data",
            "play": "play data",
            "extra": "extra data"

2 Answers 2


Single request. The user should see a unified data structure that abstracts away your database. Multiple put requests have the power cord problem, some may go through, others may not, you end up with a corrupted database.

  • Is the ended complexity on the server end worth it in your opinion? I'm asking because the fields are unrelated so they don't impact each other. Commented Aug 26, 2023 at 12:15
  • Yes. What you're proposing with multiple requests is to essentially tie the database to the front end. This makes it difficult for you to make changes in the database, and also forces all your clients to learn your internal workings. The server is under your control, the clients aren't.
    – Ccm
    Commented Aug 26, 2023 at 13:09

Normally, you'll want to have a single resource (with a single resource identifier) for both GET and PUT. The motivation is general-purpose cache invalidation - HTTP compliant components that see a successful PUT know that they can invalidate responses to earlier GET requests (rather than re-using them after the data is stale). See RFC 9111.

Having one resource that clients use to read information, and a different resource that clients use to modify information, takes cache invalidation off of the table (not completely: but since we don't have a general purpose mechanism for arbitrary cache invalidation, the number of cases we can handle correctly is greatly reduced).

It follows that introducing new resources "just" to be targets of PUT requests should not be the tool we prefer to use.

Using a PUT request to modify a resource is normal, and there is nothing in the semantics of the PUT request that cares whether the information being changed is related or independent (beyond the obvious point of contributing to the representation of the same resource).

New resources to handle POST requests runs into the same cache-validation difficulties that you get with new resources for PUT - we have only limited tools available to do cache invalidation.

What does work is to implement the original resource with a request handler that can distinguish different POST requests and apply the appropriate logic to each.

(A way of thinking about this: HTTP semantics work at the resource abstraction - the target resource identifier is what matters. The fact that your implementation separates GET/POST/PUT handlers from each other is an implementation detail hidden behind the HTTP facade.)

That said, there are trade-offs: if all of your requests are going to the same target uri, then your general purpose access logs tell an ambiguous story -- you have the uri, and the method, and other metadata, but nothing there that tells you which logical branch you are taking.

And of course you need an audience aware enough to understand that it is reasonable to use the same HTTP semantics for multiple domain semantics.

  • Thank you for your super detailed response. So according to you, I should keep it as a single big PUT request instead of multiple PUT requests? I included the POST request line merely as an after thought and a possible solution (which I now realise is not a good solution at all). Commented Aug 26, 2023 at 12:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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