We have an API platform which allows user to create and manage a certain type resource.
Client is expected to provide a callback url where our server will send notification to when the resource is updated.
So far all our notification types don't require any response from client. However, we plan to have a new type of notification which requires certain response from client, for example, someone else wants to update the resource and we need to ask client to accept or reject the update.
I see there are 2 options here:
Client get the notification, then send out a new request to our server posting its decision. We'd need to have new endpoints to handle different type of actions.
We ask client to provide http response with action in the body for this type of notification. No new API endpoint required on our side.
I'm leaning toward #2 because I don't expect client to take long time to make a decision, so completing everything in 1 round trip is more efficient then having client making another call.
The downside I see is that server won't have a chance to validate response and tell client if there's any error with the format, as client is free to put anything in the response.
Anything else I should consider? It seems #2 is the most popular option when it comes to API design, not sure if #1 is anti pattern here.