Thanks for providing this crate, I've found it really useful as a base for my jsonapi implementation.
One problem that I've run into is that the jsonapi spec allows id to be optional for create operations where an id will be generated. This library requires that all Resource objects have an id and they fail to serialize from any json resource representation that doesn't include an id field.
This might be achievable by expanding the PrimaryData definition to add an option which takes some kind of PartialResource or something. The id field of the Resource struct could be make optional, but that would violate the jsonapi spec in every case except this specific one.
I'm not sure what the right answer is, but I would appreciate it if this use case can be supported. For now I'm using dummy id values in my create requests as a workaround, but it doesn't match the behavior of other APIs we have that are implemented in other languages.
Thanks for providing this crate, I've found it really useful as a base for my jsonapi implementation.
One problem that I've run into is that the jsonapi spec allows
id
to be optional for create operations where an id will be generated. This library requires that allResource
objects have anid
and they fail to serialize from any json resource representation that doesn't include anid
field.This might be achievable by expanding the
PrimaryData
definition to add an option which takes some kind ofPartialResource
or something. Theid
field of theResource
struct could be make optional, but that would violate the jsonapi spec in every case except this specific one.I'm not sure what the right answer is, but I would appreciate it if this use case can be supported. For now I'm using dummy
id
values in my create requests as a workaround, but it doesn't match the behavior of other APIs we have that are implemented in other languages.