Is it considered RESTful to do additional things in POST api apart from creating a resource? - rest

Question

We have customer registration API that accepts name, email and mobile and generates customerId i.e.:
{
"name": "john",
"email": "john#gmail.com",
"mobile": "[phone]"
}
We create customer record for this API hit. The customer can be created from several clients and forms. We have got a new requirement that if we get this "customer creation" record from particular form, we need to send this information (name,email,mobile)+(customerId) to some third party API as well.
I believe as per resful pratise this API should only create "customer" and not do such extra things which would only be valid for certain clients/forms.
Which is the best alternative in this case:
Create new API for this new requirement: This new API would first create customer and then send it to third party API. This fulfils our requirement here but customer creation logic is now at two APIs.
Use existing "customer registration API" by adding a new flag: We would set this flag from these forms where we have this new requirement to send data to the third party as well. We would first create customer and if flag is set, we would send this data to the third party APIs as well. But is this approach RESTful?
From these forms where we need to send data to third party API, first send request to "customer registration API" and get customerId back and then send these details to third party API: This would be slow as we will have to wait for customerId on the client side.

Answer 1

POST is often used as a catch-all for actions that don't fit into a proper REST API otherwise. Bulk create, update or delete, merging records, logging in, copy, etc, are all common examples. But anything else you need to do that doesn't correspond to PUT, GET or DELETE can generally be overloaded with POST. Just make sure you use a distinct URL for each use of POST.
I.e. POST /foo should create a foo, and POST /bulk_delete should delete several fooa, based on query or form parameters.

Answer 2

I don't feel like separate resource would fit here. Let's imagine we are discussing not API endpoints design but simple class method createCustomer. Exposing a new endpoint is the same as creating a new overload method createCustomerSpecific. This is RPC-style - the number of methods will keep growing.
What REST as a style is suggesting is to use the same method, but encapsulate all the data required to create resource in the input object.
For me your case should be driven by something like repository factory: your application logics knows what repository to call - simple CustomerRepository or CustomerWithNotificationRepository.

Answer 3

I hope that the owner of this question may not need an answer for this. But here are my thoughts.
My assumptions are given below,
You have CustomerService class which contains the methods to perform CRUD operations with Customer Data.
You have an endpoint /api/customers(Method: POST) which will call the CustomerService.create() method to create a customer detail in DB.
With your second approach(Slight modification):
I prefer not to create an another endpoint since we are not doing anything differently apart from calling the 3rd party API. Hence the request JSON would be modified as like below to hold the additional data from client side.
{
"clientData": {
"notify": "true"
},
"customer": {
"name": "john",
"email": "john#gmail.com",
"mobile": "[phone]"
}
}
Post creation of the customer, We have to check whether the notify field is true or not. If its, then the 3rd party API would be called with the customer details for additional processing.