REST API: Design API to let user submit POST something and GET some value other than created Id in response

Question

It's bit lengthy but simple to understand so please read it.

We have a feedback form where the user fills the complaint/suggestions. To fill a complaint, the user needs to fill his/her {Name, Mobile Number, ZipCode}. As a response to this complaint, we show our nearest call center number based on user's pin code.

Once the user submits the feedback [name, mobile, zip code], the complete process is:

• The user sees nearest customer care contact number upfront on the screen.
• New Complaint is registered in the database.

This process needs to be integrated across platforms (Mobile, Desktop, Apps) and we need to design Restful APIs for this. Few choices:

1. GET /api/complaint/?mobile={mobile}&name={name}&zip={zipcode}. This API would send back nearest call center number in response, save record in complaint table. But this does not look restful as we are adding database records with GET request.
2. POST /api/complaint/ with {mobile},{name},{zipcode} in the request body. This too can do all above things but the problem here is that as per rest where we send back new created object in POST response, here we would send back nearest customer call center number which has nothing to do with complaint record creation in the database.
3. Create two separate APIs, first POST /api/complaint/ with {mobile},{name} that would insert a record in the complaint table. And second, create GET /api/callcenter/?zip={zipcode} which returns back the customer care number of that zipcode. There are few problems here like two APIs are decoupled so what if POST is unsuccessful while GET is executed OR vice versa? Also, hitting these two sequentially would be slow?

Which of these 3 is correct OR is there any 4th way to solve this problem?

Answer 1

I actually like the 3rd option. A failed post shouldn't affect the ability to get the nearest call center right? A failed post would be a problem in the second option as well. These call centers should already be in database. I'm sure you'll have some code/subroutine to calculate the shortest distance between any given zip code and all of the call centers. And in the third option, even though a complaint wouldn't be filed in a failed post, at least the user could get the number of the nearest call center to continue to get help

Answer 2

Teach a man to fish: almost every question in of the form "what is the REST way to do X?" has the answer "figure out how to do it with html links and forms, and match that pattern as closely as you can."

the problem here is that as per rest where we send back new created object in POST response

If that wasn't true, would it make your life easier? If so, good news....

1. REST doesn't say anything about "create"; it says that resources should conform to the uniform interface.

2. If you are communicating with your API via http(s), the uniform interface is defined by RFC 7231 (not REST; REST is an architectural style, the Web is a reference application built using that style).

3. HTTP does not say that POST must equal create.

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.

4. The HTTP specification doesn't say you have to return the created object. In fact, it says 200 OK means that you return something different:

a representation of the status of, or results obtained from the action

In your case, the status of your action is "congratulations, our attempt to find the closest care center to you succeeded. here it is...." Yes, this has nothing to do with the fact that you created a complaint record in the database. From the point of view of the web client, there is no database . Just the resources and the uniform interface.