I have a model in which I need to keep track of the time at which an instance is first created as well as the last time it was updated.
Should such information be kept as an attribute or meta?
Since it is about the resource, I would make it an attribute. I have never seen that kind of information in meta.
If I see created-at in meta, I would first assume it represents the time the document was generated.
1 Like
Usually I’m keeping createdAt & updatedAt in attributes and making them read only.
1 Like
I would defend that createdAt and updatedAt/modifiedAt should be inside meta, and not inside attributes.
My reasoning is that if you have a resource of type person, createdAt does not refer to the moment the person, who the resource is about, was created (that would be birthDate rs).
Therefore, I view these pieces of data as metadata of the resource, including dataProvider, if you need to keep track of data.
However, @maark seems to have more experience than I do with APIs. My background is in data modeling.
Thanks, @maark, I’ll look up for other implementations on how they deal with that.
P.s.: I am currently working on filtering strategies and JSON:API doesn’t seem to expect you to filter requests based on data place within meta.
An advantage of using attributes is that they can be included or excluded using fields[type]=..., which is attractive if you don’t always need them. Similar for a creator field in relationships.
That said, I’ve seen more examples of server-side frameworks treating these as metadata managed by the components in a standard configuration, and not directly managed at the application level.
I’d like something like meta[type]=..., similar to fields[type]=..., but it would be best for it to be part of the specification, if only to avoid having to think of a mixedCase name for the query parameter (metaData is just… wrong).
-Fred
1 Like
I have been thinking about that aspect too… I have wondered if an API could consider the fields within "meta" on its implementation of sparse fieldsets. So, if you wanted to retrieve only "createdAt" there would be no problem, just send fields[resourceType]=createdAt.
At least the specification seems to be silent about this.
The downside is that fields within meta/attributes/relationships cannot clash and this can become annoying as the API grows.
Right. That constraint would be backward-incompatible, since it imposes a new constraint on meta fields, so it would not be allowable. A new query parameter would be needed to avoid the backward incompatibility.
-Fred
1 Like
A bit late to the party, but to me - modulo the limitations in the jsonapi standards discussed, perhaps making this response somewhat academic, but at least a vote for future enhacement, I am in agreement with @claudenirmf that it “should” be meta if it is a quality of the resource record - and only an attribute if it is a property of the resource.
So for example a record may have been created or updated by someone at a certain time, which is recorded for audit or data synchronisation purposes, or may be (un)locked, and may have data permissions attached, and these might all reasonably be meta-data.
I think this becomes blurred when the receipt of the information is an important part of it, for example a timestamp describing its sequencing, or veracity, in which case it would be an attribute.
This potential duplication might seem confusing, but it comes down to whether it is a business meaningful attribute, or meta-data to support non-functional qualities.
… I suppose wrangling with a framework to support the intent, such as query filters or field limitations will be the driving factor for now …