json_api_client icon indicating copy to clipboard operation
json_api_client copied to clipboard

Retrieving original data on error response

Open tjjjwxzq opened this issue 8 years ago • 3 comments

I'm having trouble dealing with error responses on update.

First off, it seems that the documentation is erroneous in suggesting that an JsonApiClient::ErrorCollector object will be returned, because I'm getting an ActiveModel::Errors object instead. This isn't much of an issue, just slightly strange. Also it seems that when the error response is parsed, only the source and title fields are parsed. However the spec allows for more fields in an error object (eg. details) and I think it be good to allow customizing this behavior.

Now the main issue: on unsuccessful update of a resource, the server should respond with an errors object. However this ends up overwriting the original result set which contains included data and the like. This is troublesome as we can no longer reference associations, but this is usually needed (eg. for re-rendering the edit page for a resource, which may reference associated resources).

Currently I'm having to overwrite the update method in my BaseResource to save a copy of the last result set before making the API call, and setting the last result set to be the one before the update call, once errors have been set.

class BaseResource < JsonApiClient::Resource

  # overwrite update to clone the original
  # result set before making the API call,
  # otherwise the original data will be
  # overwritten on an error response
  def update(attrs = {})
    original_result_set = last_result_set.dup
    success = super
    unless success
      self.last_result_set = original_result_set
      false
    end
  end

Is there any other way to go about it?

tjjjwxzq avatar Jul 04 '16 09:07 tjjjwxzq

I also noticed that when using custom_endpoint it returns JsonApiClient::ErrorCollector

adis-io avatar Oct 03 '16 08:10 adis-io

Yes please! Or provide a clean way to swap json_api_client's error handler for our own.

We wrote a JSON endpoint compliant with json-api spec that returns "error" objects on both validation errors and generic client/server errors (bad route, unauthenticated, server side exceptions, etc). On the client side, we want to generically collect and log all errors based on their original http status as well as custom meta information. The behavior of raising without providing original error payload gets in the way.

egilburg avatar Oct 26 '16 01:10 egilburg

Is this still an issue?

gaorlov avatar Mar 20 '19 15:03 gaorlov