Page MenuHomePhabricator

Response alignment for routing errors between gateway, restbase and services errors
Open, Needs TriagePublic

Description

Background

Recently we realized that the way that the API is responding to routing errors has changed and it's quite different from the way that services do.

When we request something like:

https://wikimedia.org/api/rest_v1/metrics/**pageviews_invalid_route**/top/en.wikipedia/all-access/2022/01/02

we get the following error with content-type:application/json

{
    "httpReason": "Not Found",
    "httpCode": 404
}

And when we make this request:

https://wikimedia.org/api/rest_v1/**metriasdasdcs**/pageviews/top/en.wikipedia/all-access/2022/01/02

we get the following one with content-type:application/json+problem

{
    "type": "https://mediawiki.org/wiki/HyperSwitch/errors/not_found#route",
    "title": "Not found.",
    "method": "get",
    "uri": "/wikimedia.org/v1/metriasdasdcs/pageviews/top/en.wikipedia/all-access/2022/01/02"
}

But services are responding errors like the following one with content-type:application/json+problem when we request something like https://wikimedia.org/api/rest_v1/metrics/pageviews/**wrong-endpoint**/en.wikipedia/all-access/2020/12

{
    "detail": "Invalid route",
    "method": "get",
    "status": 404,
    "title": "Not Found",
    "type": "about:blank",
    "uri": "/metrics/pageviews/wrong-endpoint/en.wikipedia/all-access/2020/12"
}

So, at this moment, we have three different responses for three similar wrong request regarding the provided route.

According to what we know at this moment:

  • /api/rest_v1/metrics/ will hit the gateway
  • /api/rest_v1/blahlahalvb will hit restbase
  • any other case with a valid /api/rest_v1/metrics/right_basepath/ will hit an specific service
Goal

The goal here would be to align the response for all these errors. We should have the same response structure and content-type regardless which part (gateway, restbase or a service) is responding.

The right response structure should be the one we are using for services (the last one shown above).

Acceptance criteria
  • Same structure is used for all routing error cases
  • Same content-type (application/json+problem) is used for all routing error cases

Event Timeline

Sfaci updated the task description. (Show Details)

To be explicit about routing differences - we have a rule for /api/rest_v1/metrics/* that directs traffic to the rest gateway and we have a rule for *most* other things under /api/rest_v1/* that defaults to restbase. There are some exceptions for services that have been migrated out of restbase.

I'm not sure this problem is worth solving for now. Based on a skim of the RFC, my position is that returning application/json+problem for non-existent routes in restbase itself is not a fully correct behaviour, as this isn't an error of the API rather than simply an API that doesn't exist. Envoy does not and imo should not return json+problem manually itself because it correctly doesn't know that it's serving a specific API. Is it worth spending engineering time on getting these values in alignment?

I have the same opinion. My initial intention was just taking notes somewhere about this in order to avoid being surprised again in the near future with this behaviour and, after deciding to create a ticket, I prepared it in a way it seems we are going to work on this right now but I was just trying to imagine what would be the ideal solution. But, as you mentioned, I think it doesn't worth spending time with this at this moment (and likely in the future).
Should we just close this ticket for now?

In my opinion the service responds with desired application/json+problem when correct basepath is provided . The other responses returned by rest gateway or restbase differ and since the basepath in itself is incorrect , is not obligated to return the same response as of service