Changing ID of entity?

1

I’m currently working on a project where instead of storing entities server side, I’m encoding them into a sort of meta String. This is because these entities will potentially be PATCHED/POSTED extremely often and don’t need server side authority. For example, you could do this by having it in the meta { } section…

{
“jsonapi”: {
“version”: “1.0”
},
“data”: {
“id”: “123”,
“type”: “test”,
“attributes”: {
“foo”: “bar”
}
},
“meta”: {
“payload”: “YADFE&YEDF&” // encoded “foo: bar”
}
}

But ideally I want to be able to put the encoded entity’s data into its ID, as this will allow me to easily add them as relationships in other resources. As currently, if you wanted to pass multiple of these entities as relationships to another resource, you’d end up with some weird array business going on in the meta tags or something? So ideally something like this;

{
“jsonapi”: {
“version”: “1.0”
},
“data”: {
“id”: “YADFE&YEDF&_123”, // encoded “foo: bar”
“type”: “test”,
“attributes”: {
“foo”: “bar”
}
}
}

So an ID containing the encoded info seems like a good idea to me - the only problem then is that PATCHing the entity would affect its ID. So my question then is;

Can you let a PATCH operation on an entity change its ID? (Maybe using a 303 response to the new entity ID?)

Or otherwise, how would you handle encoded entities in this way?

Thanks

2

Yes you can do this, but I say this with a very very heavy recommendation to not do what you are proposing. You are trying to use a {json:api} service non-authoritativel which invites divergent modifications among many other problems.

I would suggest you search for tools or a methodology like a document store where use as a write back cache is more inline with your intent. You could also use event sourcing as a means to patch the log of the resource with each change being simply a record to append to the state. What I wouldn’t do is overload the well known meaning and use of ID for convenience.

The distributed solution you are proposing is a very difficult problem to completely mitigate so I would tread carefully and attempt to understand the larger problems you are casually inviting by this proposed solution.

I hope this helps!