active_model_serializers: Serializing errors

The JSON API docs currently state (I’m not sure if they said this before JSON API 1.0):

A document MUST contain at least one of the following top-level members:

data: containing the document's "primary data"
errors: containing an array of error objects
meta: non-standard meta-information.

The members data and errors MUST NOT coexist in the same document.

Is there a way to render the errors member in master / v0.10.0.rc1?

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 23 (18 by maintainers)

Most upvoted comments

This is what I use in my app:

      render json: model, status: 422, serializer: ActiveModel::Serializer::ErrorSerializer

Wanted to copy the PR description from #1004 to track further changes / remaining TODOs

Courtesy of @bf4

Usage

Requires explicit passing of Error serializer

# POST /api/{plural_resource_name}
def create  
  set_resource(resource_class.new(resource_params))

  if get_resource.save
    render :show, status: :created, adapter: :json_api
  else
    render json: get_resource.errors, status: :unprocessable_entity, adapter: :json_api, serializer: ActiveModel::Serializer::ErrorSerializer
  end
end

PR TODOS:

Error object:

Serializing errors is different from resources.

  • Errors may be an instance of ActiveModel::Error, which we’d want to call model.errors.messages on.
    • Resolution: true
  • Errors may be given as a hash.
    • Resolution: undecided
  • Errors may be given by the end-user as a special ‘error’ object.
    • Resolution undecided
  • ActiveModel::Error is necessarily a collection of error objects, each with it’s own 'source' and 'detail'
    • Resolution: that’s how we’ll use it.
  • Errors may be automatically generated from the controller.

Full Error API Implementation:

  • error root key to collection of error objects
    • The members data and errors MUST NOT coexist in the same document.
  • error objects from ActiveModel::Error
  • 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.
  • 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 query parameter caused the error.
  • meta: a meta object containing non-standard meta-information about the error.

Implementation tests:

Other implementations

ref: