[question] Add extra fields to response

[aegyed91]

I see, by design strictly only code and message are being passed to http response body.

https://github.com/restify/errors/blob/master/lib/baseClasses/HttpError.js#L92
https://github.com/restify/errors/blob/master/lib/baseClasses/HttpError.js#L147

Imagine a scenario when you want to pass down some extra metadata in the error response. For example validation details:

{
    "code": "BadRequest",
    "message": "",
    "validation": { ... }
}

How do you guys pass extra error metadata in http response?

[DonutEspresso]

If you are sending the response as JSON, the easiest way is to simply override the toJSON method with your own custom method after you create the error. It might not be a bad idea to accept an option at instance creation time to specify how you want this formatted, though!

[maoueh]

I have the following custom error:

errors.makeConstructor('ValidationError', {
  restCode: 'BadRequest',
  statusCode: 400,
});

// eslint-disable-next-line func-names
errors.ValidationError.prototype.toJSON = function () {
  const parent = HttpError.prototype.toJSON.apply(this);
  parent.details = this.errorDetail;

  return parent;
};

Which is called like this:

new ValidationError({ message: 'Body is invalid', errorDetail: errors }

However, from my toJSON override, I'm not able to retrieve the errorDetail field passed at construction. However, the extra properties seems to not be available on the Error object.

So, I've used HttpError.context field instead to carry around the details.

// Error definition
parent.details = this.context;

// Usage
new ValidationError({ message: 'Body is invalid', context: errors }

I was just wondering if it's the right way to go or if I'm hijacking the HttpError.context property?

[maoueh]

@tsm91 I think you settled on not exposing it by default. Since you were about to expose it, can I assume it's ok for my to use context for such use case?

[aegyed91]

@maoueh i would say yes, anything goes

but i believe the usage for context property would be for internal logging mechanism, so one who reads the logs can understand a bit more about the error itself

also, why would you want to send back validation data to client? Client should handle validation errors before form is submitted.

[maoueh]

The client should indeed, and it will, but backend could do some validations the client won't do (checking for a duplicated or something more fancy).

And I would like to send this validation. Also, for those use the API more in cURL/Postman way, not having the actual messages is a pain. So I always prefer to send validation errors back to client so it is able to display them to user.

[aegyed91]

the client won't do (checking for a duplicated or something more fancy).

why not? I usually got async validators when the situation requires it. For signup you implement an endpoint to check if the email address provided is taken or not. Based on that u return a http 400 which the client intercepts as email addr is taken.

And I would like to send this validation. Also, for those use the API more in cURL/Postman way, not having the actual messages is a pain.

I use postman as well. I usually log the extra information to console. You dont have to send it back in the response. Also with Bunyan u could log these infos in production as well.

What i plan on doing is investigate https://github.com/restify/errors#bunyan-support and https://github.com/trentm/node-bunyan. To implement a proper logging system that works in dev and prod as well.

[DonutEspresso]

Hey @maoueh, the example you have is the right way to do it:

new ValidationError({ message: 'Body is invalid', context: errors }

The API is covered over here in the README. If this doesn't work for you feel free to open a new ticket!

[aegyed91]

@maoueh what i did is implemented a loggerService, which can properly write errors to process.stdout on serverside

this way when you test api-s you can read the logs in the console instead of sending validation errors to client. Link to example usage part 1, part 2, serializer implementation

it looks like this