Любой запрос, поступающий на веб-сервер, должен в соответствии с go первоначальной проверкой, я бы предположил, проверить, существует ли запрошенный URL или нет. Как только это подтверждается, запрос затем переходит к потоку, который обрабатывает его на основе некоторой бизнес-логики c.
С этим допущением, не должно ли ошибка 404 (несуществующий URL-адрес) возвращаться быстрее чем обрабатывается запрос и возвращается статус ошибки из-за неудачной проверки?
Если это так, то в качестве следствия имеет смысл проектировать ваши REST-API так, чтобы они имели фиксированные конечные точки, а не чем конечные точки, которые принимают параметр пути. Например, в приведенном ниже коде (Swagger-codegen) я определил такой API-интерфейс - / resource / {operation}, где operation - это параметр пути, который может принимать значения, такие как - get, getAll, add /
{
"paths": [
"/resource/{operation}": {
"post": {
"operationId": "handleResource",
"parameters": [
{
"name": "operation",
"in": "path",
"type": "string",
"required": true
}
]
}
}
]
}
Приведенное выше определение создает интерфейс службы с методом handleResource(String operation), где мне нужно будет проверить operation.
Вместо того, чтобы проектировать ваши API в качестве фиксированных конечных точек -
- / ресурс / get
- / resource / getAll
- / resource / add
должен быть более производительным, поскольку у вас нет параметров пути.
TLDR; Значит, параметры пути - это плохой дизайн REST-API?