q: resource error types about rest-layer HOT 5 CLOSED

What do you mean exactly? A new kind of "standard" error to be returned by the methods of this interface for instance? If you return other errors than ones defined in the doc, it will just generate a 520 response with the error's message as description (see https://github.com/rs/rest-layer/blob/master/rest/errors.go#L46). Would you prefer a specific handling for general DB failure?

I'd like to keep this interface as generic as possible. A Storer implementation may not be backed by a DB.

from rest-layer.

I typically return a 502 for backend system errors. To me, that's more accurate than an 520 with a paradoxical error string. I didn't notice the catch-all error handling until you pointed it out, and that certainly will address my issue.

That said, I would be happy to see a new standard error in errors.go that mapped to 502. In the case where the Storer isn't backed by a different service, one could stick with the 520. Thoughts?

from rest-layer.

But how is a 502 (bad gateway) relevant for such an error?

from rest-layer.

By liberally interpreting the API server as a proxy/gateway to the database :-) Interestingly, the only significant reference I found to handling errors from a backend database system comes from here: http://restcookbook.com/HTTP%20Methods/400-vs-500/. They suggest using a 500 or 503 depending on the nature of the problem.

In any case, after I thought about it a while, I'd say that consistency with the Eve project trumps the specific generic error code in my mind. I haven't done any coding with it yet, but hope to use both projects to provide consistent APIs across all of our service.

Please close this ticket unless you think there is more to explore, and thanks for your quick dialogue.

from rest-layer.

The Eve compat is actually not a reason here, I didn't try to make it Eve compatible, just inspired by Eve. The default API output isn't compatible with Eve anyway. I just get all the good ideas from Eve :)

Ok to close, we may think about making this "customizable" in the future if it become a concern for several people.

Thanks for you feedback!

from rest-layer.