I am making an application in which there are 3 tables. A user can click a button to request to move an item from table 1 to table 2. Essentially, this means that an item is deleted from table 1 and an item is posted to table 2. However, I assume it would be worse performance to make 2 http requests since I could technically make the changes on 1 request.

Is there a type of http request for this scenario that I'm not thinking of? How would you handle this scenario?

  • A new HTTP method you mean? What's wrong with POST?
    – Andres F.
    May 30, 2019 at 20:40
  • 3
    Don't assume that some arbitrary operation is going to cause performance problems until you test it first. That said, if this is considered an atomic operation, just use a POST for the whole thing and stop worrying about which HTTP verbs to use. May 30, 2019 at 20:42
  • Are you actually changing the entity type when moving an item to another table? Why move the data to another table? Why not simply have a type column or a mapping table?
    – Dan Wilson
    May 30, 2019 at 20:58
  • @AndresF. I'm both posting and deleting so I didn't think post would convey that.
    – Gwater17
    May 30, 2019 at 21:42
  • @DanWilson Yeah I could do this
    – Gwater17
    May 30, 2019 at 21:43

2 Answers 2


It seems to me you're probably thinking of an operation where a resource (the "item") in your system is updated in some way, possibly within a transaction. This update can very well result in this entity moving from one table to another table. Another likely characteristic of your operation is that it's not idempotent; i.e. you cannot move an entity twice from A to B. The second time you attempt this is probably an error.

An HTTP POST is the perfect request method for this kind of operations, where you're modifying a resource in a non-idempotent way.

Note that considerations of performance ("is it more performant to do it in one or two HTTP requests?") are premature unless you measure them and find they really impact your system. First you should focus on what makes sense for your system.

  • I would think the operation IS idempotent. POSTing twice results in two copies of the object being created and is not therefore idempotent. Moving an object, like DELETE of an object is idempotent even if the second attempt causes an error.
    – Jon Guiton
    Nov 25, 2020 at 15:54
  • @JonGuiton I agree the right choice is not clear cut, and I'm actually not sure I agree with my own answer now. But if performing the operation twice results in an error the second time, then by definition it's not an idempotent operation. Idempotency means performing the operation once or multiple times is observably identical; an error is a difference and would break idempotency. I agree you could say this is a PUT operation to move the resource, and that PUT'ing twice could silently do nothing the second time.
    – Andres F.
    Nov 25, 2020 at 16:45

How would you handle this scenario?

How would you do it with a web site? In HTML, you'd probably have a form, and using input controls you would collect the information that you need, and when the form was submitted the appropriate request would be created by the client and dispatched to the server.

From the sound of things, the semantics of this are unsafe, so you would normally use POST.

You could use multiple forms if you wanted to -- but multiple forms aren't better REST than using a single form.

Given that, how do you do it with a REST API? Same thing.

Is there a type of http request for this scenario that I'm not thinking of?

The way to figure out if there is a suitable HTTP method that has already been standarized is to look at the HTTP Method Registry. You can read through them all -- but more likely, look at the names, and follow up to read the reference to see if the semantics actually match what you are trying to do.

For instance MOVE is defined by the WebDAV specification. So you could review that standard to see if the details of the semantics actually match your use case.

In practice - you probably aren't going to get a lot of advantage from the less common metrics -- they rather depend on having clients (and intermediate components) that were built with those semantics in mind. POST has the advantage of being ubiquitous.

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.