I see some services which takes a requestId from client as the mandatory attribute while some services doesn't. I feel it is a good idea to have a request Id from the clients because it helps in debugging through logs, that is, what happened with this request.

Can someone provide the good reasoning or the best practice for the API to have the requestId?

Should the requestId be unique from clients?

Also, is there any benefit of storing this id in the database or its just for logging purpose? Currently, I don't see any benefit in database, but still wanted to ask.

  • 1
    Can you provide an example of this? REST API or another sort? – Dan1701 Feb 14 '19 at 7:18

If your service is an asynchronous service, a request ID is useful or even mandatory, because when the service wants to send data back, the client knows which request the data belongs to. If it's a long-running process, the client could even use the request ID to poll your service about the progress or status. Note that either your service should generate those IDs, or you need to have some other way to make sure the IDs specified by clients are unique (e.g. by using GUIDs).

For synchronous services, I wouldn't bother with requesting them. Usually, the timestamp of a request is enough to dig up the relevant information from the log. If you have a high-volume service and the log clutters, you can always generate an identifier on your site, log some basic information (username, other identifying information in the call) with it, and use that identifier. If I would need to specify a request ID as a client of your service, I would consider that unnecessary housekeeping.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.