Making a virtual property vs meta data for datetime field

1

I have a resource with a datetime field say ‘expiry’. This ‘expiry’ field should be updated from server with ‘x’ hours added to it when client request a PATCH. In JSONAPI, client cannot send datetime as PATCH data for updating due to timezone issues.

I am having a thought of implementing one of the below ways,

  1. Making a virtual boolean field [sending as resource property like ‘expiry_active’] for ‘expiry’ field. Now client can send this virtual boolean field as PATCH data so that i can update the ‘expiry’ datetime field as sideeffect.
  2. I can send the same boolean data in META data. In this case, is there any possibility to send the meta data alone as PATCH from client so that i can update the datetime field as sideeffect?.

Is there any other way to address the above scenario?

2

I don’t understand this. Your clients should send timezone-neutral data or data including the timezone they’re referencing. This shouldn’t be an issue.

Also, given that the server should update the expiry, I don’t even see why anything is sent from the client in this regard.

3

@OliverSalzburg Thanks for your reply

  1. Will investigate more on timezone-neutral data from client side.
  2. Regarding ‘server should update the expiry’ - the datetime field should be updated when the end user action on a particular button say toggles a button, server needs to set the expiry time with ‘n’ hours added to current time. This is not a side-effect and this field is the only data that should be updated on user action.
4

How 'CRUD’ful is your API?

If your design, documentation, and paradigm assume the same representation in and out than you have a problem. This is usually solved as a subresource to encapsulate the ‘message’ you want to send.

The other option is to include a redundant property of what essentially is round_floor(now - expiry), which you can update as desired in the front end by saying current ‘expiry + field value’ on the patch or just the value, but you’re going to confuse someone no matter how you decide to do it.

The cause of the problem isn’t datetimes or timezones, its that your design probably doesn’t take into account that resources != objects, and can accept other messages than their normal or default representation (projection).