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": "..."
    }
}

score 3 · Accepted Answer · edited Oct 07 '21 at 08:57

3

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.

edited Oct 07 '21 at 08:57

Community

1
1

answered Apr 20 '17 at 13:47

Eric Stein

13,209
3
37
52

I think this is the right answer, I'll accept this. One last question though: what if the services provider has already developed a "framework" that reads those data in a JSON section of the body request? What is the best option: change all endpoint to be POST (violating REST but consider that all request are Intranet and not indexable, cacheable) or forcing the provider to adhere to the standard for the greater good? Thank you for your answer. – Dinux Apr 20 '17 at 14:12
You should probably allow more time for other answers before accepting one. Some people are dissuaded from answering if one is already accepted. As for your question, that's somewhere between opinon-based and unanswerable. My opinion would be if there's one client and there will only ever be one client, you can do whatever you want. I'm not sure who "the provider" is in this question, but I'd prefer using headers and/or JWT if there's not that much information. – Eric Stein Apr 20 '17 at 14:43
You're right about accepting too early, but in this case, IMHO, you gave a complete answer that is exactly what I was searching for. In fact, my client already use JWT tokens, but he decided to "design" all the endpoints as POST and put those data in the body. I'm not happy with this, but I will survive. Many thanks. – Dinux Apr 20 '17 at 15:28

score 0 · Answer 2 · answered Apr 20 '17 at 08:16

0

Usually, the information called "technicalData" are not sharing between client and server by request call. You should share only a request token that identify the current session. The token will be related on the server with loggedUser and so on...

answered Apr 20 '17 at 08:16

ADIMO

1,107
12
24

That is a client requirement. Services resides on a ESB middleware that is unaware of the types, users logged in, BPM transaction ID and other external information. – Dinux Apr 20 '17 at 08:26
If the Service is unaware of the types, users logged in then you shouldn't logged this information but only the ip and timestamp. – ADIMO Apr 20 '17 at 08:37
It's a client requirement, I cannot say that I don't want to pass log information required by the specification of the architecture already in place. – Dinux Apr 20 '17 at 09:16

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

2 Answers2