-
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
Response hypermedia for single objects and arrays #15
Comments
How about using reflection to fill relations for each object? I've done some initial works here. The changes are part of #14 (undone). What I don't quite follow is why we're caching the relations to the response. Because for the array case, the data structure |
For a singular resource, caching on the response is sufficient. Accessing "/users/1" will store all of the user's relations on the response. When we access the relations of the "/users/1" URL, it includes any link headers and the user's relations all together. user, res := req.Get(&User{})
res.Rels.Rel("repository", ...) You're right though, this doesn't work for collections. That's why I'm proposing that we don't even bother trying to parse the collection. If we need to access the relations of an object, then we do it explicitly. users, res := req.Get(&[]User{})
res.Rels.Rel("next", ...) // links to page 2 of the collection
for _, u := range users {
hypermedia.Rel(u, "repository", ...)
} Maybe this is too confusing though? It might be nice to have a single way to access the relations of any object. users, res := req.Get(&[]User{})
hypermedia.Rel(res, "next", ...)
hypermedia.Rel(users[0], "repository", ...) The relations cache could also be completely separate from the response cache. If you get a collection of users, it could save the relations cache for each user. I like that idea. Though, I don't know what the cache interface for that would look like. users, res := req.Get(&[]User{}) // fills relations cache for every returned user
hypermedia.LookupRel("/users/1", "repository", ...) // accesses relations cache
hypermedia.Rel(users[0], "repository", ...) // accesses relations on struct itself |
What do you think of this: users := []User{}
res := req.Get(&users)
for _, u := range users {
u.Rel("repository", ...)
} We do a bit more work in |
Don't we have to jump through hoops to get that to work? Go's embedded structs don't allow the kind of inheritance we're used to in Ruby. Functions like |
Yes, you're right that things aren't easy comparing to Ruby. But it's possible. We already embed a hypermedia struct to each object. In But As a side note though, do we need to support method call like |
It just feels like we're fighting against Go. It's like the difference between rels := hypermedia.LookupRels("/users/1")
rels.Rel("repository", ...)
rels.Rel("keys", ...)
We don't need to. However, we are thinking of moving to HAL in a future API media type change. Supporting |
Ah, got ya!
Totally forgot you mentioned it. Thanks for putting me back on track with the road map. It's a benefit to work with someone who knows what'll happen under the cover 😸. Let's try out One more question, for line users := []User{}
req.Get(&users)
rels := hypermedia.LookupRels(users[0])
rels.Rel("repository", ...)
rels.Rel("keys", ...) |
I'm thinking |
🆒 I'm more clear now. Thanks for the explanation. |
Sawyer assumes API requests return a single object. It then merges that object's hypermedia relations (HAL or similar) with the response's hypermedia (pulled from Link headers). This presents a problem for API responses that return an array of items:
How should we handle that? My proposal is that we don't try to merge an object's hypermedia into the response's hypermedia if the resource is an Array. If you need to access the relations of one of the objects in the array, call Rels() on that individual object.
The text was updated successfully, but these errors were encountered: