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:
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.
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 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.
Hello,
First, thank you a lot for your amazing library @mattpolzin !
I don't know all the JSON::API v1.1 additions, but the
lidmember 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
UUIDfor theidand sometimes it's created on the app side. Until now, the back-ends accept to theidmember as the theidto save in the database... but it's not perfect... and I think that the newlidwould 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
lidpart, but I need to know your plan about the spec 1.1 before to start on this.