q: resource error types

[jxstanford]

I'm writing a Storer implementation, and definitely appreciate the detailed comments, and example implementations. Does it makes sense to have an error to cover general DB failures unrelated to the specific operation (such as connection error)?

[rs]

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.

[jxstanford]

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?

[rs]

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

[jxstanford]

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.

[rs]

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!