A command as the intended effect of POST versus as the side effect of PUT

Question

The intended effect (semantics) of the POST method is resource specific, e.g. executing a command with arguments:

POST /command HTTP/1.1

{"parameter-1": "argument-1", "parameter-2": "argument-2"}

The intended effect (semantics) of the PUT method is to create or replace the state of the target resource with the state defined by the enclosed representation, but the side effect of the PUT method is resource specific, e.g. executing a command with arguments:

PUT /command HTTP/1.1

{"parameter-1": "argument-1", "parameter-2": "argument-2"}

Cf. RFC 7231, § 4.3.4:

A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.

So what are the benefits of executing a command as the intended effect of POST versus as the side effect of PUT?

If this is essentially, RPC (Remote Procedure Call), I wouldn't use a PUT for this. Semantically speaking, the result of executing an arbitrary command is, well, arbitrary, and is therefore the province of a POST, not a PUT. — Robert Harvey, Jun 28 '21 at 17:48
@RobertHarvey Do you mean that if the state of the `/command` resource has no purpose (the user is not interested in retrieving it with GET), use POST instead of PUT? — Géry Ogam, Jun 28 '21 at 18:26
No, that's not what I meant. What I meant was: PUT has a semantic meaning that doesn't encompass arbitrary code execution. POST is the *wild-card* verb; you can use it for anything you want, including arbitrary code execution. — Robert Harvey, Jun 28 '21 at 21:54
In the first place, `A PUT request applied to the target resource`. It's not like you are pointing or handling any resource, you are merely executing remote procedures. Don't know if method semantics applies here. I would dare to say that it doesn't matter whether you use POST or PUT. I'm somewhat sure that you are not returning the header "Resource-Location" + 204 Status after POSTing a command. So why you care about semantics? — Laiv, Jun 29 '21 at 08:00
@Laiv I care about semantics because the difference between an intended effect and a side effect is important. For instance if the command is placing an order on an e-commerce website, it is very important that the customer intended that HTTP request effect i.e. be aware for it. You do not want to place an order as a side effect of an HTTP request i.e. without the customer’s consent. — Géry Ogam, Jun 30 '21 at 00:20

score 3 · Answer 1 · answered Jun 28 '21 at 17:12

If I PUT a resource representation, then the expectation is that a GET of the same resource returns an equivalent representation. For example, if I PUT /command with body print("hello world"), when a later GET /command might get back the command, or the result of executing the command.

A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response.

(RFC 7231)

With a POST, there is no expectation of the resource at that URL being created or updated. It is quite common that a POST to an URL creates a different resource (to which a 303 See Other or 201 Created response might redirect). But a POST might not touch upon any resources, and be invoked purely for its side effects.

For example, let's consider a HTTP-based version control system. Each version is identified by an URL like /version/d1623a5. There are also floating labels like /version/latest. How would different designs create a new version?

In a PUT-based design, I might directly create a version resource by PUTting a new representation to its URL:
```
> PUT /version/c0af447
>
> the new content

< 201 Created
```
As a side effect, this might update the resource that /version/latest points to. Such a PUT is also idempotent. If it fails, I can safely retry it. If the version resource already exists, I would probably get a 204 No Content response.

Alternatively, I might PUT the latest version:
```
> PUT /version/latest
>
> the new content

< 204 No Content
```
As a side effect, this might create the resource /version/c0af447.
In a POST-based design, I would not directly POST to the version resources, but to a URL that creates new versions:
```
> POST /version/new
>
> the new content

< 303 See Other
< Location: /version/c0af447
```
This cannot be retried safely: a repeated POST request would typically create another version.

In practice, using POST is still very popular because it is quite general-purpose, and is less constrained than a PUT. It is a reasonable default for changing “something” on the server.

‘`PUT /version/latest` As a side effect, this might create the resource `/version/c0af447`.’ So a repeated PUT request would create another version resource, like with `POST /version/new`. — Géry Ogam, Jun 28 '21 at 19:42
@Maggyero Not necessarily. PUT is about *replacing* the representation. If I `PUT /version/latest` and the representation that I PUT is equivalent to the representation that already is there, the request wouldn't change anything. This is quite different to `/version/new` which has no current representation. — amon, Jun 28 '21 at 20:06

JimmyJames · Accepted Answer · 2021-06-28T17:33:19.257

1

As you state in the question the difference is intent. A side effect of a PUT should not matter to the caller and they are not responsible for it. The intended effect of a POST is what the caller is doing and is their responsibility. If you control both the client and server, you are pretty free to do what you like but I don't see any good reason to break convention.

However, if your intended effect (not side-effect) is idempotent, PUT can be used (RFC7231 section 4.2.2)

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

edited Jun 28 '21 at 17:33

answered Jun 28 '21 at 17:03

JimmyJames

24,682
2
50
92

‘However, if your intended effect (not side-effect) is idempotent, PUT can be used’ Actually the intended effect of PUT is always idempotent since it consists in creating or replacing the target resource’s state. – Géry Ogam Jun 28 '21 at 17:49
@Maggyero I think you are confusing the semantics of the HTTP requests and resources with what happens when you change them. – JimmyJames Jun 28 '21 at 17:51
1

@Maggyero For example, let's say I ran a web server for home automation, I could have a resource for a garage door. When you put it's state to close, it closes (or stays closed), that's the intended effect and this would be a valid use of `PUT`. If I have one for my fish feeder, calling it repeatedly would dump more food in the tank and probably kill the fish. `PUT` would not be appropriate for that. – JimmyJames Jun 28 '21 at 17:55
I like your examples ;) But my understanding is that the *intended* effect is ‘put its state to close’ and the *side* effect is ‘it closes (or stays closed)’. Because it seems consistent with the current version example given in RFC 7231, § 4.3.4: ‘A PUT request applied to the target resource can have **side** effects on other resources. […] A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.’ – Géry Ogam Jun 28 '21 at 18:00
Also it seems consistent with RFC 7231, § 4.2.2: ‘Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, **or implement other non-idempotent side effects for each idempotent request.**’ – Géry Ogam Jun 28 '21 at 18:18
2

@Maggyero Closing the door (if it's open) is part of the intended effect i.e. when I call it, I intend to make the door close if it is open. A non-idempotent side effect would be something like the state of the electric meter changed to reflect the energy used. Closing the door multiple times results in the same state for the door but not for the meter. It's a 'side effect' because the services intent is to modify the door state, not to change the meter reading. PUT calls are allowed to have non-idempotent side effects but not non-idempotent intended effects. – JimmyJames Jun 28 '21 at 18:27
I think you are confusing the user’s intent with the method’s intent. I agree that the user’s intent is to close the door when he sends a PUT request on the resource, but PUT’s *primary* intent (intended effect) is to update the state of the resource, and its *secondary* intent (side effect) is to close the door, which is also the user’s intent. – Géry Ogam Jun 28 '21 at 18:37
@Maggyero By definition, 'intended effect' is what the user intended. Side effects are things that happen which are not the intended effect. I can't find language in the RFC ATM but the basic example is if you are running a retail site, when someone calls POST from their browser, the intent is to place an order. You can put the some functionality under a PUT as well. The difference is that if the user calls that PUT multiple times, you cannot place multiple orders and charge them multiple times but if it's a POST, you can. – JimmyJames Jun 28 '21 at 18:49
‘when someone calls POST from their browser, the intent is to place an order.’ I agree, POST allows any intended effects, like placing an order, contrary to other methods (GET, PUT, DELETE) whose intended effects are restricted to CRUD operations on the resource state (but that does not prevent from having *side* effects, i.e. other effects, like placing an order). ‘You can put the some functionality under a PUT as well.’ Yes but only as a side effect since the intended effect is already defined, contrary to POST. So when repeated, you *can* place multiple orders, but you keep the same state. – Géry Ogam Jun 28 '21 at 19:29
2

@Maggyero Placing an order is not a reasonable side effect unless the caller of this operation bears no responsibility for that order. In other words, as a web site operator you can place orders all you want as a side effect of a PUT but you (the web site operator) must pay for them because there was no intention to place them by the user. 'Side effect' means something other than the 'intended effect'. The whole point is you can do basically whatever you want to execute the intended effect but none of those side effects are the user's responsibility. – JimmyJames Jun 28 '21 at 19:38
1

It might help to look at 4.2.1 which is referenced by 4.2.2 "... does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. **What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it.**" That's the point. The user is only accountable for their intended actions and PUT should be designed so that the intended result is the same if you call it once or 100 times. – JimmyJames Jun 28 '21 at 19:46
One thing I'm noticing is that there seem to be a lot of people getting tripped up on the meaning of 'side effects' in this context. I think maybe people are confusing it with the idea of side effects in functional programming where it means any state change at all. Side effects in the RFCs are things that happen 'aside' from the intended effect. More like side effects of a medication. – JimmyJames Jun 28 '21 at 19:53
‘I think maybe people are confusing it with the idea of side effects in functional programming where it means any state change at all.’ I think this is actually the same definition if we consider that the intended effect of a function is to return a value (cf. [this answer](https://softwareengineering.stackexchange.com/a/262000/184279)). – Géry Ogam Jun 29 '21 at 20:22
@Maggyero The answer you point to is not the (pure) FP understanding of side-effect. Look at the accepted answer on that question. That's the FP definition I am referring to in my last comment: "It's really very simple. Side effect = changing something somewhere." To be clear, it's a perfectly well-defined term in that context, it's just not the definition that the RFC is using. The RFC language is more akin to the answer you point to. – JimmyJames Jun 29 '21 at 20:43
‘Side effect = changing something somewhere.’ This definition does not seem to conflict with the other definition that I am pointing at, which is side effect = unintended effect, since changing a state is unintended in the context of functional programming. This [other answer](https://softwareengineering.stackexchange.com/a/325520/184279) makes the same remark. – Géry Ogam Jun 29 '21 at 21:10
@Maggyero The accepted answer literally contradicts that sentence: "A side effect does not have to be hidden or unexpected" – JimmyJames Jun 29 '21 at 21:13
@Maggyero We really are getting into a lot of semantic games here and I'm frankly not very interested in them. I am fully aware of what words mean in English, I don't need or want to debate the meaning of 'is'. – JimmyJames Jun 29 '21 at 21:15
Reading again Didier A.’s [illuminating answer](https://softwareengineering.stackexchange.com/a/325520/184279), I think I understand where the semantic confusion comes from. As he explained: ‘In more general term, a side effect is any effect which is not the intended effect of the designer of the construct.’ So this intended/side effect property is **relative to a particular construct.** For instance, a state change is a side effect *for a function,* but not necessarily *for a procedure,* for which it can be an intended effect. – Géry Ogam Jun 29 '21 at 22:39
So equating ‘state change’ with ’side effect’ like Aaronaught does in the [accepted answer](https://softwareengineering.stackexchange.com/a/40314/184279) is a misuse of language. His statement ‘A side effect does not have to be hidden or unexpected’ really means ‘A *state change* does not have to be hidden or unexpected’, i.e. ‘A *state change* does not have to be a side effect’, which is correct, e.g. for a procedure. – Géry Ogam Jun 29 '21 at 22:39
Thus we have cleared up the definitions of *intended effect* and *side effect* by stating that they are about the *construct designer’s* intent (here the constructs are the HTTP methods), and since the user chooses to call them they are also about the *user’s* intent (so we were both correct). GET, PUT, and DELETE are intended to have a CRUD effect (read for GET, create and update for PUT, and delete for DELETE) and POST is intended to a have resource-specific effect. – Géry Ogam Jun 29 '21 at 23:56
Back to my original question ‘what are the benefits of executing a command as the intended effect of POST versus as the side effect of PUT?’, we can restate it as ‘what are the benefits of an intended effect versus a side effect?’, which does not make a lot of sense. For instance, like you said, placing an order should be an intended effect of POST to be user intended (i.e. user be responsible for it), and it should be a side effect of any method, like PUT, to be user unintended (i.e. user not be responsible for it). – Géry Ogam Jun 29 '21 at 23:56
‘However, if your intended effect (not side-effect) is idempotent, PUT can be used’ That is a very subtle remark: the user is supposed to use a method for its intended effect (specified by its designer), not for its side effect (unspecified by its designer). But you can pervert this and use PUT for its side effect as long as the side effect is idempotent, since then it can be safely repeated automatically by the user agent in case of network failure i.e. the user’s intended effect perverted as a PUT side effect would be the same as if it was requested only once like with POST. – Géry Ogam Jun 30 '21 at 01:18
@Maggyero "But you can pervert this and use PUT for its side effect as long as the side effect is idempotent, ..." I'm not clear if you are coming from the client or server perspective here. From the client perspective, it's unclear how you would know about this side effect and there would be no reason to expect the server to always support that side effect because its not part of the API's contract. If you depend on unspecified features or behaviors, you are asking for problems in the long run. On the server side, you are free to do whatever you like with side effects. – JimmyJames Jun 30 '21 at 14:16
‘From the client perspective, it's unclear how you would know about this side effect and there would be no reason to expect the server to always support that side effect because its not part of the API's contract.’ I totally agree. I was just trying to interpret your statement: ‘However, if your intended effect (not side-effect) is idempotent, PUT can be used’. So if you did not suggest a perverted use of the side effect of PUT, what did you really mean by this sentence? – Géry Ogam Jun 30 '21 at 15:06
To conclude this interesting discussion, could you clarify your final statement: ‘However, if your intended effect (not side-effect) is idempotent, PUT can be used’? Did you mean that if your intended effect is to create or replace the target resource’s state, which is an idempotent effect, then PUT can be used? – Géry Ogam Jul 05 '21 at 10:50
@Maggyero I'm not sure what you are asking. This whole discussion is about how PUT's intended effect should be idempotent and you can do whatever you like with side effects as long as the caller isn't accountable for them. – JimmyJames Jul 06 '21 at 14:12
My bad, I am realizing that I have already asked you this question in the first comment. I should have concluded that your initial statement: ‘As you state in the question the difference is **intent.**’ conflicts with your final statement: ‘However, if your intended effect (not side-effect) is **idempotent,** `PUT` can be used.’ Either the choice of method for your effect is about its intent, or about its idempotence. And I agree with the former (so your final statement should be removed). If your intent is to create/replace the target resource’s state then choose PUT, else choose POST. – Géry Ogam Jul 06 '21 at 15:29
@Maggyero I really don't understand what conflicts you are talking about. 'Intent' and 'intended' are different forms of the same word. If the intended effect of the operation is idempotent, you can use PUT. If the intent of your operation is not idempotent, you should use POST. I don't really know how many more different ways I can say this and it's all there in the RFC. – JimmyJames Jul 06 '21 at 15:53
‘If the intended effect of the operation is idempotent, you can use PUT.’ This would violate the HTTP specification; PUT is for creating/replacing the target resource’s state, any other effect is a *side* effect of PUT’s definition (i.e. unintended by the user). That is like if you used GET for deleting a resource; you would violate its definition. This is the point I have been trying to make in this discussion. – Géry Ogam Jul 06 '21 at 16:56
"‘If the intended effect of the operation is idempotent, you can use PUT.’ This would violate the HTTP specification; " That is the [specification](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2). The RFC states: "A request method is considered "idempotent" if the **intended effect** on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent." – JimmyJames Jul 06 '21 at 17:02
And it goes on to say: "Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is *free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.*" We've covered this at least 3 times already. – JimmyJames Jul 06 '21 at 17:04
Yes, that means PUT’s intended effect (creating/replacing the target resource’s state) is idempotent. That does *not* mean: you can change PUT’s intended effect (creating/replacing the target resource’s state) with another one as long as it is idempotent. – Géry Ogam Jul 06 '21 at 17:08
@Maggyero I really have no idea what you are talking about. I'm basically 50% certain you are a troll. – JimmyJames Jul 06 '21 at 17:10
Otherwise if we follow your logic, since GET is idempotent too, this would mean that you could use GET for an idempotent effect such as shutting down a server. Which I think you will agree is obviously wrong. In other words, PUT’s intended effect is already defined by the HTTP specification (creating/replacing the target resource’s state), you cannot override it like for POST which is specially defined as being overridable (‘resource specific’). – Géry Ogam Jul 06 '21 at 17:18
@Maggyero GET is safe. All safe methods are idempotent but have additional requirements. [RTFM](https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.1). – JimmyJames Jul 06 '21 at 17:26
The section you referred states: ‘What is important, however, is that **the client did not request that additional behavior** and cannot be held accountable for it.’ and ‘Likewise, a safe request initiated by selecting an advertisement on the Web will often have the ***side* effect** of charging an advertising account.’ So you cannot say that you can use GET for any other *intended* effect than the specified one (retrieving a representation of the target resource’s state). And same reasoning for DELETE which is idempotent too. – Géry Ogam Jul 06 '21 at 17:39
@Maggyero We are going in circles: it's all comes back to intent. Reread the answer and all the comments again. Read the RFC. We have already covered this ground. Unless you have something new that we haven't already discussed multiple times, please stop asking the same questions again and again. It's all there in plain English. – JimmyJames Jul 06 '21 at 17:44
‘it's all comes back to intent.’ [Exactly](https://datatracker.ietf.org/doc/html/rfc7231#section-4.1): if your intent is to retrieve a representation of the target resource’s state then use GET, if your intent is to update the target resource’s state then use PUT, if your intent is to delete the target resource’s state then use DELETE, if your intent is target resource specific (e.g. shutting down a server) then use POST. So the choice of method is not about **idempotence**. It is about **intent** (that is for this precise statement that I accepted your answer in the first place). – Géry Ogam Jul 06 '21 at 18:37
@Maggyero "So the method choice has nothing to do with idempotence. It is about intent" That is a bizarre interpretation of the spec. It literally calls out that [PUT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT) should be idempotent (for the intended effect). This is common knowledge: "The difference between PUT and POST is that PUT is idempotent". How can you even begin to argue that the choice between methods has nothing to do with idempotency? – JimmyJames Jul 06 '21 at 18:42
Maybe an example about why GET needs to be 'safe' might help. When your browser comes across an `img` tag, it will do a GET against that resource automatically. The reason it can do that is because there's no reason to expect that GET to cause any issues. If you want to make a GET operation that shuts down your server, you can do that, but then all I need to do is get an admin to open a page (or email) with an `img` tag pointing to that resource and I just brought your server down. – JimmyJames Jul 06 '21 at 18:51
‘How can you even begin to argue that the choice between methods has nothing to do with idempotency?’ If the choice of method was only based on the method *property* (safe, idempotent, or cacheable), then why would the specification define the *intended effect* of each method (read/update/delete the target resource’s state for GET/PUT/DELETE)? – Géry Ogam Jul 06 '21 at 18:55
@Maggyero "If the choice of method was only about the method property (safe, idempotent, or cacheable), then why would the specification define the intended effect of each method (read/update/delete the target resource’s state for GET/PUT/DELETE)?" I never claimed it was 'only' about intent. That's absolutely confused interpretation of everything I've written here. The whole point of this answer is that you need to understand intent to evaluate whether the operation is idempotent because that's what the spec says: the idempotency requirement of PUT applies solely to the intended effect. – JimmyJames Jul 06 '21 at 19:07
If the choice of method didn't relate to the method property then why would the specification define these as requirements in the first place? – JimmyJames Jul 06 '21 at 19:09
Okay, I think that the crux of our debate lies in these two possible interpretations: 1. Mine, which is that the *intended* effect of a request method is *fully* defined by the HTTP specification (read/update/delete the target resource’s state for GET/PUT/DELETE, target resource specific for POST, etc.). 2. Yours, which is that the *intended* effect of a request method is *partly* defined by the HTTP specification and can be *extended* by the target resource’s owner (e.g. reboot a machine). Do you agree with this presentation of the issue? – Géry Ogam Jul 06 '21 at 21:01
1

@Maggyero I would say that the RFC specifically calls out examples of 'real world' effects such as "charging an advertising account" that are not 'fully defined' i.e. they aren't defined at all. I don't speak for you but if you are denying that, then yes, I disagree with you on that point. – JimmyJames Jul 06 '21 at 21:17
Yes but the specification explicitly describes the charging of an advertising account as a *side* effect of a safe request method, not as part of the *intended* effect, which means that the user is *not* responsible for it. Here we are specifically debating *intended* effects, i.e. effects for which the user is responsible. – Géry Ogam Jul 06 '21 at 21:35
So to me interpretation 1 is still the correct interpretation of the HTTP specification, but I am not 100% sure, what about you? This is important to get this right because it has major implications: interpretation 2 implies that a resource’s owner can choose *any* HTTP methods for implementing a non-standard intended effect (e.g. rebooting a machine) in addition to the standard intended effects of the HTTP methods, as long as they share the *same* properties (safe, idempotent, or cacheable), whereas interpretation 1 implies that he can only choose *POST*. – Géry Ogam Jul 07 '21 at 09:05
"Yes but the specification explicitly describes the charging of an advertising account as a side effect of a safe request method, not as part of the intended effect, which means that the user is not responsible for it" Yes exactly, that's why it's OK to do it in a GET because it's not the user's problem. If you were expecting the user to pay for that, don't use GET. It's really that simple. – JimmyJames Jul 07 '21 at 17:33
1

@Maggyero "I am not 100% sure, what about you?" I am 100% sure that your interpretation #1 is wrong. There's not a single doubt in my mind because the RFC is very clear. If you use GET to cause things to happen, it's on you and you alone, you cannot hold the users responsible. If you use PUT to cause non-idempotent things to happen, again, it on you. If you want to hold the user responsible for non-idempotent things, use POST. That way when they hit 'back' on the their browser they will get a warning that they may be charged again or be responsible for whatever the real-world impact is. – JimmyJames Jul 07 '21 at 17:39
Section 4.3.3 of the RFC gives an example that I have a relevant anecdote about. It list as as an example of using POST for "Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;" I used to be on a programming forum back in early 2000s which had instead used GET to post messages to a thread. Someone figured it out and crafted a link which, when clicked on, would post something like: "{username} is an April's Fool!" and created a thread with the link in the question. It was a funny way to expose what was essentially a vulnerability. – JimmyJames Jul 07 '21 at 17:59
Thanks for the clarifications Jimmy. Now let’s see what [other people think](https://softwareengineering.stackexchange.com/q/430043/184279). I am also going to email the IETF HTTP Working Group to get an authoritative answer. – Géry Ogam Jul 07 '21 at 21:46
[I realized](https://softwareengineering.stackexchange.com/a/430058/184279) that all effects such as shutting down a machine and charging an advertising account are actually changes in resource’s state. So shutting down a machine matches the *intended* effect of PUT i.e. it replaces the target resource’s state, and therefore it is not a *side* effect under interpretation 1 nor an *extra intended* effect under interpretation 2. And charging an advertising account does not match the *intended* effect of PUT and is not idempotent, and therefore it is a *side* effect under interpretations 1 and 2. – Géry Ogam Jul 10 '21 at 01:20
I also realized that interpretation 2 (the intended effect of a method is *partially* defined by the HTTP specification) does not make sense since it means that a method can be implemented with two method effects, like a PUT which would replace the target resource’s state *and* delete the target resource’s URI like DELETE. – Géry Ogam Jul 10 '21 at 01:22
You actually agreed with interpretation 1 (the intended effect of a method is *fully* defined by the HTTP specification) which validates all that you said. It is just the implications of interpretation 1 (shutting down a machine can only be a side effect of PUT) which were wrong, now that we know that all effects are changes in resource’s state (so shutting down a machine can actually be an intended effect of PUT). – Géry Ogam Jul 10 '21 at 01:22
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/127390/discussion-between-jimmyjames-and-maggyero). – JimmyJames Jul 10 '21 at 14:39

A command as the intended effect of POST versus as the side effect of PUT

2 Answers2

Linked