-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Telemetry for unmatched Endpoints #984
Comments
This is interesting. How popular is this HTTP 410 and the version header pattern? We're generally trying not to be opinionated about certain decisions when it comes to structuring HTTP apps. While both 405 (MethodNotAllowed) and 415 (UnsupportedMediaType) seems to be generic enough to provide support from within a library, I don't feel so sure about 410 (Gone). |
I haven't seen any API that actually uses 410 in the wild. Versioning seems to be one of these infamous problems that everyone solves on his own. ;-) However, there are opinions about this matter out there, e.g.: https://webmasters.stackexchange.com/questions/71152/what-is-the-correct-http-status-code-for-this-version-of-this-api-has-been-dis |
It would be convenient if it was possible to asses for what reason an endpoint did not match. For example: If part of your API is versioned, you might want to differentiate between a request that did not match any paths (in which case the API responds 404 or 405) and one that matched a path but the client's version was outdated (e.g., 410).
To further clarify what I'm aiming at, here is how I currently solve the problem. I use a custom endpoint that checks a header-value and sets a field in the context of the finagle request if the endpoint did not match. This value is then read in a finagle filter and a corresponding response is constructed. Below you can find the sourcecode for a possible implementation of such a version-endpoint:
The text was updated successfully, but these errors were encountered: