wip: rest response sizes #1
Conversation
|
@philsturgeon can you give me some feedback up to this point? |
| "relationships": { | ||
| "user": { | ||
| "links": { | ||
| "self": "https://apisyouwonthate.com/api/users/11122/relationships/user", |
There was a problem hiding this comment.
I wonder if this is just begging for confusion. JSON:API does not always appear to be the most concise or obvious thing in the world, so trying to use this as an example here might just complicate the explanation. I'm not sure there.
Are we trying to move the manager info out?
Perhaps a better example would be invoices. People often mix invoices, with payments and payment attempts, and status of those payments as it traces through the bank, which is confusing as fuck.
| { | ||
| "type": "User", | ||
| "id": 1, | ||
| "attributes": { |
There was a problem hiding this comment.
If you keep this example then maybe split it out into "positions" or "roles" and explain that the extra split is actually a useful feature: you can have multiple roles at the company, you may switch roles, slowly transitin from one to the other with overlap, etc. Usually the extra resources provide extra functionality. :)
There was a problem hiding this comment.
Im going to go with the invoice example, seems more straight forward :)
|
|
||
| ### Wrongly modeled data. | ||
|
|
||
| In conjunction with the above, another reason people complain about REST response sizes being so large is that developers have not modeled the data for the requests. Lets consider the example above. In it, we have two requests we are making, ```/api/users``` and ```/api/users/11122```. In the first request, we should return the least amount of data possible. When making the first GET request, which returns all the resources for the given endpoint, model your data to return the bare minimum. In this case, a userId and a name. |
There was a problem hiding this comment.
have not modeled the data for the requests
not sure what this means
| } | ||
| ``` | ||
|
|
||
| And that's all you need! Along with hypermedia, the other data is close by but now our response is more concise and easier to use. |
There was a problem hiding this comment.
Maybe we could add that "the other benefit to having smaller payloads with links for more data to grab if the client wants it" is "these smaller more targeted resources might be http cached, meaning when your client goes to fetch more data avout crashy's positions, its right there in the HTTP client cache. =Insert link to article=.
| categories: jekyll update | ||
| --- | ||
|
|
||
| One of the biggest complaints people have about REST is that the response size is too big. In reality though, that is not a REST problem, that is a problem with the developers maintaining that endpoint. Let's look at some reasons why and how we can mitigate it. |
There was a problem hiding this comment.
Oh shit very first thing maybe you could say "This argument is a huge misnomer because OData and JSON-API, etc have sparse fieldsets (you can request only the fields you want" which is almost certainly the inspiration for the GraphQL feature.
wip