search

Jaymon / endpoints

Lightweight REST api backend framework that automatically maps urls to python modules and classes
MIT License
29 stars 10 forks source link

HTTP Warning header #113

Open Jaymon opened 3 years ago

Jaymon commented 3 years ago

Should Endpoints use these for error message? It might be deprecated

Links:

jgrisham commented 2 years ago

The new draft justifies depreciation based on a claim that all mainstream user agents ignore that header.

So, using it shouldn’t harm anything (but there’s always the risk it could be re-activated in the future so its probably best to follow the existing semantics).

There were several revisions of an Internet Draft (that expired last spring) (on GitHub) that was aiming to provide something similar for API usage.

Edit: there appears to be a standards-track RFC purpose-made for this sort of thing: RFC 7807 Problem Details for HTTP APIs

Jaymon commented 2 years ago

This is cool, thank you for sharing. I'll look into RFC7807 when I finally get to making the error handling better

Jaymon commented 8 months ago

I think json errors can use this when an Exception or list of exceptions is all that is in the Response body in development and by default:

I think production errors could use this format but it would make more sense to return whatever is the agreed upon with the frontend.

I think the warning header can be used in systems that have debug activated or something like that, that way testing production ready systems will use the agreed error body format but if they are in the dev or staging we can set the warning header with additional information on the raised errors to help frontend debug.

When I actually get around to implementing this I think this is the direction I will go.