-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add etag and collections #91
Conversation
fa49ad0
to
8af43d1
Compare
// RESPONSE | ||
200 OK | ||
Content-Type: application/json | ||
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From our convo this morning the above seems great. This line seems redundant.
Search returns a list so Header is invalid and inclusion of ETag in Body makes sense (Response Body *not Request body)
Get By ID: There is only 1 so Header works but having the Etag in both the Header and Body feels redundant.. not the worst thing but can we standardize on 1 instead of both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. But it also feels inconsistent with an ETag being optional in a resource object as part of a collection and required when returned individually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me its similar reasoning to including the status code in the body of error message (impacts logging, convenience, etc). In this case specifically, its the intersection of two patterns, where we want data model consistency between your resources returned in collection or singular, but also consistency to other resources by id that use ETag as the more industry norm pattern for individual results.
I think for consistency, both are necessary depending on how the consumer will make use of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. I can see why we wouldn't want multiple schema's to represent the same thing and/or context specific schemas.
Co-authored-by: Nick Clarity <[email protected]> Signed-off-by: Travis Gosselin <[email protected]>
@omnipitous / @nickclarity / @PavlenkoV - I appreciate your expertise, effort, and review on this one. |
This update introduces the addition of ETag to collection responses, allowing clients to track versioning for individual resources within a collection. By including an ETag for each item, we enable efficient caching and conditional operations, reducing unnecessary API calls and improving performance. The ETag is added as a read-only field in the response body to ensure version consistency without altering the API's general object model.
This solution can serve as an interim approach until a standardized HATEOAS implementation is adopted.