How to design RESTful services with server side logging capability of client information

Question

I'm designing RESTful web services to expose functionalities in a SOA Architecture. Clients of the services are logged in the enterprise intranet, have a client name, ID and other technical information (not business relevant I mean).

I have a requirement which says that all calls to the RESTful services must be logged and must contain the client "not business" information (id, application name, logged user, etc.).

I want to collect all the technical information in a JSON object "technicalData" and the business data (the 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 GET/DELETE body does not have a semantic meaning to the request since they are used only for logging purpose 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": "..."
    }
}

Answer 1

No, you shouldn't pass that information in the body of every request. You certainly shouldn't pass it up the wire in GET and DELETE calls, as that violates the spec:

sending a payload body on a GET request might cause some existing implementations to reject the request. (RFC 7231)

sending a payload body on a DELETE request might cause some existing implementations to reject the request. (RFC 7231)

Meta information like this belongs in headers. Presumably you're using an Authorization header or other means of identifying the user? That will give you the username. If not, maybe the From header would be an appropriate place to store it. Perhaps User-Agent can be used to specify the application. Alternately, look at using a JWT, which will let you embed arbitrary information.