Replies: 1 comment
-
Personally, I would avoid having multiple lookups per resource and keep the structure flat. Instead, rather use the JSON:API relationship object to link what relationship a category has to a catalog or visa-versa. This makes the API more user-friendly, as someone does not have to have two parameters to get the details of only one resource. Because of the relationship object, in my opinion, the JSON:API spec favors a flat design. However, you could, of course, create your own There might be different perspective on this issue though, so converted this to a discussion for further conversations on this topic. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Description of feature request
I'm not sure if this is a feature request, or a bug report, or simply my not understand the framework correctly.
It seems to be impossible to use ResourceRelatedField objects to refer to nested resources.
For example, in my model I have something like:
store/123/catalogues/222/categories
There are two ID path parameters in that URl. So in my catalogue serializer I want to do something like this:
but I can't see any way to do that, meaning the serializer errors when it tries to use the view. Am I missing something or is it not possible to use ResourceRelatedFields for these sorts of nested resources?
I couldn't see this covered in the documentation. Is there an alternative way I should be doing it?
Beta Was this translation helpful? Give feedback.
All reactions