RESTful API Question

Let's say when a user do an action, I need to insert a record into a table and then update a record in different table.

Should I write two API routes (PUT, POST) or one route (POST) ?

There’s no rightway or written rule to do it, but most would say that PUT for update? Take it with a grain of salt

Different resources, different endpoints. Though sometimes you have to be a little pragmatic and do it your own way.

Use two endpoints. For the first, create endpoint, use POST if you don't already have the resource identifier (like id, that gets created on server side), otherwise use PUT. The second endpoint should be PATCH if you update an exisiting resource.

my rule of thumb is: If you create somethin where you don't know the ID, use POST. If you update an object with a known ID and you will submit the whole object, use PUT (overwrite). If you update only a member of a setting (not whole object will be sent), then use PATCH.

In your use case it is not clear if the initial POST will or should trigger the other update mechanism as well or if the business logic is implemented on client side and those operations are independently.

If your use case always includes two actions combine them in one one API call (in your case PUT or PATCH).

Your API is not an interface to the Database. Your API is an interface to the Business Logic. Soooo depends on your Business Logic :D

But as a general Rule of Thumb:
Different Resources = Different URLs
Different Operations (update,create) = Different HTTP Verb (PUT, POST)

Remember PUT should be idempotent whereas POST shouldn't be. Not that any api I've ever seen in the real world seems to respect that.

@Robinha then you haven't seen the API's I have designed 😎😁

The REST in RESTful stands for what you won't get if using it and for what it should be left to do in peace.

Use GraphQL.

From what I remember, PATCH is for updates

@h4xx3r patch is for partial updates, correct. Put is for overriding an entire resource.

@dodomo good to know, never had the need to totally override something, patching all the way 😁

GET = getting info from id
POST = create an entry
PUT = overwrite all the object at id
PATCH = change a field in a row at id
OPTION = return values where post put patch can take

This is my little rule for rest api

@jak645 agreed. The only thing I understand differently is POST. I think I've read somewhere that it's kind of a default Verb. Not meaning anything particular. You can use it for anything the other verbs don't already do.

+ The ID part of your rule is a little misleading. It's all relative to the URI.

The I would do is -

If my insertion is idempotent i.e. every insertion results in the same value then PUT (usually we just return an error, when someone tries to put the same resource again like Bad Request or Conflict)

POST for every other insertion or update.

Then when the request is received and controller is executed, you can call your business code via a service and do both db updates at once or just fire an event which can be processed by listeners.

These listeners then individually do the insertion part.

I would say POST for exclusive creation with no ID specified, and PUT for creation or updation (?) with a specific ID.

If the record in the other table have to be updated every time you post no matter what. If it’s unthinkable that someone would post something without needing to update that record also, then you should definitely only have a single endpoint.

Having to call two endpoints to perform one action is unintuitive

Also, you can’t be sure that everyone using the api will remember to call both endpoints every time, meaning your data has the potential to end up inconsistent