You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thank you a lot for your amazing library @mattpolzin !
I don't know all the JSON::API v1.1 additions, but the lid member seems very interesting:
The id member is not required when the resource object originates at the client and represents a new resource to be created on the server. In that case, a client MAY include a lid member to uniquely identify the resource by type locally within the document.
I often need sync data created on the device in my applications. So I use the type UUID for the id and sometimes it's created on the app side. Until now, the back-ends accept to the id member as the the id to save in the database... but it's not perfect... and I think that the new lid would be a lot better.
Do you have plan to allow to use JSON::API v1.1 with your library? Maybe I could try to implement this lid part, but I need to know your plan about the spec 1.1 before to start on this.
The text was updated successfully, but these errors were encountered:
Thanks for the feature request and offer to help implement it!
I don't currently have a roadmap for v1.1 support. I also don't have plans to add full v1.1 support based on not having time to commit to that scale of work right now.
Given that, I am slightly concerned that implementing v1.1 features one at a time in a silo could lead to an end result that is not very ergonomic to work with in Swift.
Still, reading the linked spec information on lid, it feels like a fairly safe isolated addition.
If you'd be willing to work through your idea for how to implement this in a thread on this issue with me I'd be in support of adding it! I do suggest we talk through the implementation before you submit a PR, though.
Hello,
First, thank you a lot for your amazing library @mattpolzin !
I don't know all the JSON::API v1.1 additions, but the
lid
member seems very interesting:Reference: https://jsonapi.org/format/1.1/#document-resource-objects
I often need sync data created on the device in my applications. So I use the type
UUID
for theid
and sometimes it's created on the app side. Until now, the back-ends accept to theid
member as the theid
to save in the database... but it's not perfect... and I think that the newlid
would be a lot better.Do you have plan to allow to use JSON::API v1.1 with your library? Maybe I could try to implement this
lid
part, but I need to know your plan about the spec 1.1 before to start on this.The text was updated successfully, but these errors were encountered: