HTTP method for Express REST API with Postgres

Question

I am implementing REST APIS using Express and Postgres. In an endpoint, I would like to first delete all the instances from a table by FK user_id, and then insert several new instances with the same user_id. I'm wondering which http method should I use in this case? Currently I use POST but I don't know if this is the appropriate way. It seems that using PUT also works fine.

router.post('/myTable', auth, async (req, res) => {
  const client = await pool.connect();
  try {
    await client.query('BEGIN');
    const { records } = req.body;
    await client.query('DELETE FROM my_table WHERE user_id=$1', [req.user_id]);
    for (i in records) {
      await client.query('INSERT INTO my_table (name, user_id) VALUES ($1, $2)',[records[i], req.user_id]);
    }

    await client.query('COMMIT');
    res.send();
    
  } catch (error) {
    console.log(error);
    await client.query('ROLLBACK');
  } finally {
    client.release();
  }
});

Answer 1

PUT is for creating/replacing the resource at the URI you specified.

So if a resource exists, it has a URI that client knows, and with a PUT request you are replacing what's there, PUT makes the most sense.

One great benefit of PUT over POST is that PUT is idempotent.

So if you are sending a PUT request to a /myTable endpoint, the implied meaning is that you are replacing myTable, and a subsequent GET request on that same endpoint would give you a semantically similar response of what you just sent.

If any of my above assumptions are wrong, chances are you'll want POST, which is more of a general catch-all method for making changes with fewer restrictions. The downside is that I think it's less obvious what the operation of a given POST request is without inspecting/understanding the body and you lose the idempotence benefit too.

Answer 2

Currently I use POST but I don't know if this is the appropriate way.

Rule #1: if you aren't sure, it is okay to use POST.

POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”

---

It seems that using PUT also works fine.

In a sense, any method "works fine" at the origin server. HTTP defines request semantics -- what the messages mean. It doesn't constrain the implementation.

However, general purpose clients are going to assume that your server understands GET/HEAD/POST/PUT etc exactly the same way that every other web server understands them. That's a big part of the power of the REST architectural style - any standards compliant client can talk to any standards compliant server, and it just works. Furthermore, it continues to work exactly the same way if we stick any standards compliant cache/proxy in between them.

But if you respond to a PUT request with 204 No Content, then general purpose components are going to understand that to mean the same thing that any other server would return. Which is to say, your server is responsible if your deviation from the standard results in loss of property.

Answer 3

You can check the answers here for your reference. They are very well explained. PUT vs. POST in REST

But since both could serve the same purpose and would only depend on your preference or requirements, I usually use post for creating a resource and put for updating one as a practice.