Hi,
I would like to use the error.detail field to display customised errors messages for the front end. After some study, I'd like to explore some options of enhancement on ValidationErrors:
Attribute :base should be treated as the primary resource entity instead of an attribute
Currently, :base is being treated as an attribute in source.point, e.g. "source": { "pointer": "/data/attributes/base" }. However, according to rails's doc at http://api.rubyonrails.org/classes/ActiveModel/Errors.html, "attribute should be set to :base if the error is not directly associated with a single attribute." The pointer can be improved by pointing to '/data' as JSONAPI Spec's 'MAY' spec at http://jsonapi.org/format/#errors. And it will provide consistency with Rails as well.
Will be be preferable if ValidationErrors use messages as detail with prefixing
My reasoning is on JSONAPI spec's "MAY" recommendations on title and detail say:
- 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.
It seems that rails's error messages behave more closely to JSONAPI Spec's detail as they allow dynamically use %{value}, %{attribute}, and %{model} to provide specifics to this occurrence. So JSONAPI spec's detail may just be rails's error message.
However, in ValidationErrors#json_api_error, it prefixes the message with the attribute and a hyphen. This may be not always desirable as some, as in my case, would prefer to use their customized validation messages as is for client facing UI.
detail: "#{format_key(attr_key)} - #{message}"
Of course, we can just use the title as it is the error message as is at the moment. But it will slightly deviate from the title's MAY recomendation.
This can be even taken a step further to allow users to provide custmised ValidationErrors in resource.rb to define their user of the title, detail, code and other fields in JSONAPI Spec's error object. But that may take some futher elaboration.
It will be nice to take them into consideration.
Many thanks,
Mytram
Hi,
I would like to use the
error.detailfield to display customised errors messages for the front end. After some study, I'd like to explore some options of enhancement on ValidationErrors:Attribute
:baseshould be treated as the primary resource entity instead of an attributeCurrently,
:baseis being treated as an attribute in source.point, e.g."source": { "pointer": "/data/attributes/base" }. However, according to rails's doc at http://api.rubyonrails.org/classes/ActiveModel/Errors.html, "attribute should be set to :base if the error is not directly associated with a single attribute." Thepointercan be improved by pointing to'/data'as JSONAPI Spec's 'MAY' spec at http://jsonapi.org/format/#errors. And it will provide consistency with Rails as well.Will be be preferable if ValidationErrors use messages as detail with prefixing
My reasoning is on JSONAPI spec's "MAY" recommendations on
titleanddetailsay:It seems that rails's error messages behave more closely to JSONAPI Spec's
detailas they allow dynamically use%{value},%{attribute}, and%{model}to provide specifics to this occurrence. So JSONAPI spec'sdetailmay just be rails's error message.However, in
ValidationErrors#json_api_error, it prefixes the message with the attribute and a hyphen. This may be not always desirable as some, as in my case, would prefer to use their customized validation messages as is for client facing UI.detail: "#{format_key(attr_key)} - #{message}"Of course, we can just use the
titleas it is the error message as is at the moment. But it will slightly deviate from thetitle's MAY recomendation.This can be even taken a step further to allow users to provide custmised ValidationErrors in
resource.rbto define their user of thetitle,detail,codeand other fields in JSONAPI Spec's error object. But that may take some futher elaboration.It will be nice to take them into consideration.
Many thanks,
Mytram