7

Is it weird to have an identifier such as (_id) on a request which you send to the API, which "enriches" the request and sends back a response with the same identifier (but obviously more enriched data)?

For example - you send request {_id: 1111} and get back a response {_id: 1111, occurence: new, etc}.

The reason why I feel it is a bit strange is because I am essentially sending and receiving the same field so my brain says it is code smell, but when looking at it logically it makes sense since I am sending over something that needs to be enriched (make certain calculations based on the identifier) and the reason that I have an identifier on the response is so that I can match the results back on the front end.

Hopefully, this makes sense and if you guys need more details please just let me know and I will add them.

Thanks all!

Improve this question

2 Answers 2

Reset to default
5

This is ok. Consider when you are asking "tell me everything about record X". Well everything about record X, includes its ID. It would seem a bit strange to ask about everything for a record, and NOT get its ID back. I'd generally prefer to pull this data back despite the slight additional overhead.

In the case where you don't need everything, and its just a subset or calculation based on the data, it's still preferred practice IMO. Your response is more complete. The id serves as a check and can be used to program defensively.

It's like asking someone a question. "What's 2+2". When they answer just 4, how do you know they are answering your question or they are answering someone else's question through their bluetooth headset? If they answer "2+2 =4", then you have a built-in check on the integrity of your response.

The question really is to what extent do you want to make your messages dependent on their operational context. If they have an ID, they are less dependent on their operational context. This means they are less tightly coupled, which is generally good practice.

Improve this answer
3
  • The only thing is that it is not asking about everything for record X it is just saying give some things about record X - specifically record X's occurrence in the database (which is a calculated value). Do you still think it is good practice? Thank you for your time and answer!
    – SurrealSyntax
    Commented Nov 8, 2016 at 16:41
  • 1
    I have edited my answer to address your comment.
    – Bradley Thomas
    Commented Nov 8, 2016 at 16:47
  • 1
    "If they have an ID, they are less dependent on their operational context. This means they are less tightly coupled, which is generally good practice." - that is what I was looking for. Thank you so much!
    – SurrealSyntax
    Commented Nov 8, 2016 at 16:52
3

It's not strictly necessary with a synchronous request. It has a really low cost and can be useful for troubleshooting. It can help you tie transactions together across systems. If one isn't supplied, I would recommend generating one (e.g. a UUID) and return it for the same reasons.

Improve this answer
4
  • 2
    And in asynchronous or messaging architectures you'd be lost without the id in the returned data.
    – Michael Green
    Commented Nov 8, 2016 at 16:59
  • I would consider it bad practice NOT to include the ID, or something that unambiguously indicates what the response refers to.
    – user244218
    Commented Nov 16, 2016 at 19:34
  • @mickeyf Maybe? You wouldn't do that in a method call within an application, right? A synchronous call to a service is different only in that it's going across a network. It can be helpful but I necessarily call it bad practice.
    – JimmyJames
    Commented Nov 16, 2016 at 19:47
  • @JimmyJames Sorry, I meant when async, should have spelled that out. yes, when sync it may be just baggage.
    – user244218
    Commented Nov 17, 2016 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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