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
TL;DR: When deserializing an instance of Error, certain properties defined by the spec are dropped -- is this intentional and, if so, why?
The JSON:API spec states that error objects MAY have the following members:
id: a unique identifier for this particular occurrence of the problem. links: a links object containing the following members: about: a link that leads to further details about this particular occurrence of the problem. status: the HTTP status code applicable to this problem, expressed as a string value. code: an application-specific error code, expressed as a string value. title: a short, human-readable summary of the problem that SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization. detail: a human-readable explanation specific to this occurrence of the problem. Like title, this field’s value can be localized. source: an object containing references to the source of the error, optionally including any of the following members: pointer: a JSON Pointer [RFC6901] to the associated entity in the request document [e.g. "/data" for a primary data object, or "/data/attributes/title" for a specific attribute]. parameter: a string indicating which URI query parameter caused the error. meta: a meta object containing non-standard meta-information about the error.
However, when serializing an instance of Error, the id, links, links.about, source, source.pointer, source.parameter, and meta members are not supported:
If all of the JSON:API error object properties were supported, then custom errors could package up all of the related data and then be reused throughout an application while still maintaining Error class semantics. I realize that the serializeError function can also be passed an arbitrary object that gets validated, but this doesn't seem ideal.
Proposed usage:
// errors/my-custom-error.jsclassMyCustomerErrorextendsError{constructor(message='Lorem ipsum dolor...'){super(message)this.status=500this.code='abc123'this.title='MyCustomError'this.detail=messagethis.id='a745776d-08bc-486d-85ed-edc38dd120a0'this.links={about: 'https://examples.com'}this.source={pointer: '/data/attributes/title',parameter: 'include'}this.meta={time: Date.now()}}}// somewhere/else.jsconstserializedError=Serializer.serializeError(newMyCustomerError())
I'm happy to submit a PR if this is something you'd like to include. Thanks!
The text was updated successfully, but these errors were encountered:
Improves the serialization of errors to be compliant with the JSON:API
spec:
* Remove explicit check for `Error` instances and, instead, validate
both instances of `Error` and POJOs using `validateError`
* Restrict `links` object properties to `about`
* Restrict `links.about` object property type to string
* Restrict `source` object properties to `pointer` and `parameter`
* Restrict `meta` object property type to object
* Add function for validating `status` against a list of known HTTP
status codes
* Restrict `status` object property type to number
* Support both `status` and `statusCode` properties
* Add tests for new functionality
* Update tests for changed functionality
* Update README.md with additional usage examples
closes#110closes#111
TL;DR: When deserializing an instance of
Error
, certain properties defined by the spec are dropped -- is this intentional and, if so, why?The JSON:API spec states that error objects MAY have the following members:
However, when serializing an instance of
Error
, theid
,links
,links.about
,source
,source.pointer
,source.parameter
, andmeta
members are not supported:json-api-serializer/lib/JSONAPISerializer.js
Lines 411 to 419 in f99b2c0
Current implementation:
If all of the JSON:API error object properties were supported, then custom errors could package up all of the related data and then be reused throughout an application while still maintaining
Error
class semantics. I realize that theserializeError
function can also be passed an arbitrary object that gets validated, but this doesn't seem ideal.Proposed usage:
I'm happy to submit a PR if this is something you'd like to include. Thanks!
The text was updated successfully, but these errors were encountered: