How to Build RESTful Services with Server Side Logging Capability for Client Information
I am developing RESTful web services to expose SOA functionality. Service clients register on the corporate intranet, have the client name, ID, and other technical information (irrelevant, I mean).
I have a requirement that says that all calls to RESTful services must be registered and must contain information about the non-business client (id, application name, logged in user, etc.).
I want to collect all technical information in a JSON object "technical data" and business data (data transfer object) for PUT / POST in another JSON object "dto".
Is it correct to put this information in the request body for GET, POST, PUT, DELETE?
This information in the body of the GET / DELETE has no semantic meaning to the request as they are only used for logging purposes see this answer on SO
Examples:
GET /books?author=AUTHOR
{
"technicalData":
{
"id": "...",
"loggedUser": "...",
"applicationName": "..."
}
}
POST /books
{
"technicalData":
{
"id": "...",
"loggedUser": "...",
"applicationName": "..."
}
"dto":
{
...
}
}
PUT /books/ID
{
"technicalData":
{
"id": "...",
"loggedUser": "...",
"applicationName": "..."
}
"dto":
{
...
}
}
DELETE /books/ID
{
"technicalData":
{
"id": "...",
"loggedUser": "...",
"applicationName": "..."
}
}
source to share
No, you shouldn't pass this information in the body of every request. You should of course not transmit it over the wire in GET and DELETE calls, as this violates the specification:
sending a payload body on a GET request may cause some existing implementations to reject the request. ( RFC 7231 )
sending a payload body on a DELETE request may cause some existing implementations to reject the request. ( RFC 7231 )
Meta information like this belongs to headers. Presumably you are using a header Authorization
or other means of identifying the user? This will give you a username. If not, perhaps the From header would be a suitable place to store it. Perhaps the User-Agent can be used to specify the application. Alternatively, consider a use JWT
that will allow you to insert arbitrary information.
source to share