Каков правильный код состояния HTTP для: «Эта версия этого API более не поддерживается»?


13

У меня есть RESTful API. Есть 3 версии: v1, v2 и v3. Я собираюсь опубликовать v4, и мы решили прекратить v1, что означает, что все запросы http://example.com/v1/resourceне будут выполнены, но вызовы http://example.com/v2/resourceпродолжат работать.

Как правильно обозначить ошибку? Я рассмотрел использование 410 GONEкода состояния, но это означает, что ресурс больше не доступен. Вероятно, ресурс все еще доступен, но только он должен запрашиваться другим способом.

Я также рассмотрел общий 400код состояния, но это тоже казалось странным. Есть ли стандартный ответ на это?


Нет кода состояния HTTP для сбоя API, потому что API не имеют ничего общего с HTTP. Вы говорите, что ресурс все еще доступен, но его нужно запрашивать другим способом, чем в REST, это не тот же ресурс, поэтому нет, он недоступен.
Роб

Ответы:


11

Там, кажется, нет стандарта.

Ответ StackOverflow опирается на 410 GONE, но я думаю, что 301 MOVED PERMANENTLY более уместен.

Чтобы сделать правильный выбор, мы должны рассмотреть ваш конкретный случай. Если ваша цель состоит в том, чтобы все вызовы в API v1 не выполнялись без каких-либо дальнейших действий, 410 GONE работает для этого. Если вы хотите некоторой преемственности, такой как перенаправление клиента на более новую версию вашего API, где его вызов может быть успешным, 3XX работает, но какой вы выбираете? Я думаю, что если вы пытаетесь закрыть API v1, 301 MOVED PERMANENTLY помогает указать, что лучше, чем 303 SEE OTHER, потому что 301 предполагает, что все будущие запросы должны быть сделаны на новый URL, тогда как 303 не указывает, является ли эта ситуация постоянны.

Я бы порекомендовал спроектировать API таким образом, чтобы каждая версия оставалась обратно совместимой, чтобы 301 MOVED PERMANENTLY прозрачно поддерживал ваш API в актуальном состоянии, когда вы добавляете новые конечные точки для новых версий API. Я думаю, это то, что вы пытаетесь сделать в любом случае.

Коды состояния HTTP

Код состояния HTTP 302 изначально был слишком широким и, следовательно, стал неправильно реализованным / использованным, поэтому были созданы 303 и 307, чтобы различать вариант двойного использования 302. Некоторые API используют 303 для других целей.

301 MOVED PERMANENTLY - код состояния 301 (Moved Permanently) указывает, что целевому ресурсу был назначен новый постоянный URI, и любые будущие ссылки на этот ресурс должны использовать один из вложенных URI.

302 НАЙДЕН. - Код состояния 302 (Найдено) указывает, что целевой ресурс временно находится под другим URI. Поскольку перенаправление может иногда изменяться, клиент должен продолжать использовать эффективный URI запроса для будущих запросов.

303 SEE OTHER - ответ 303 на запрос GET указывает, что у исходного сервера нет представления целевого ресурса, который может быть передан сервером по HTTP. Однако значение поля Location относится к ресурсу, который является описательным для целевого ресурса, так что выполнение запроса поиска на этом другом ресурсе может привести к представлению, которое будет полезным для получателей, не подразумевая, что оно представляет исходный целевой ресурс.

410 GONE - код состояния 410 (Gone) указывает, что доступ к целевому ресурсу больше не доступен на исходном сервере и что это условие, вероятно, будет постоянным. Если исходный сервер не знает или не имеет возможности определить, является ли условие постоянным, вместо этого следует использовать код состояния 404 (не найден).

Как существующие API справляются с этим?

Может быть, вы можете взять страницу из Google API Google :

При сбое запроса API YouTube возвращает код ответа HTTP 4xx или 5xx, который в целом идентифицирует ошибку, а также ответ XML, который предоставляет более конкретную информацию об ошибках, которые привели к ошибке. Для каждой ошибки XML-ответ включает в себя элемент домена, элемент кода и, возможно, элемент местоположения.

  • BigCommerce API использует 302 FOUND.
  • Atlassian REST API Guidelines указывает на 301 MOVED PERMANENTLY вместе с субкодом, который подробно описывает ошибку. Это похоже на подход YouTube API.

Дальнейшее чтение:


2
301 кажется опасным. Это может привести к автоматическому перенаправлению в место, которое может не иметь такого же канонического значения.
Брэндон Ярбро

Цените вход. Все коды 3XX указывают, что клиент должен выполнить дополнительное действие (перенаправление), указав альтернативный URL в заголовке Location. Интересно отметить, что каждый код имеет немного отличающееся поведение перенаправления; 303 перенаправит POST в новое место как GET. Я, конечно, буду обновлять этот ответ с дополнительной информацией.
Перри

1

Перенаправления отлично подходят для ресурсов, которые были перемещены. Вместо постоянного перенаправления 301 (которое указывало бы на переименование без изменений API), я бы использовал перенаправление 303 «Просмотреть другие».


0

Нужно еще поддерживать наследие без перенаправлений? Даже если вы все еще поддерживаете его, и в глубине души он все еще реализован, 501 кажется довольно тесно связан с вашей ситуацией. Те, кто в курсе, все еще могут использовать его, в то время как случайные люди увидят 501 для v1.

10.5.2 501 не реализовано

Сервер не поддерживает функциональность, необходимую для выполнения запроса. Это подходящий ответ, когда сервер не распознает метод запроса и не может поддерживать его для какого-либо ресурса.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


0

Я бы использовал 503 с сообщением о том, что сервис недоступен, и указал бы использовать более новую версию. Это сообщение можно вернуть для 50% звонков и со временем постепенно увеличить до 100%.

Для прозрачной миграции я бы использовал 308 - постоянное перенаправление, так как этот метод не изменяет глагол (POST будет POST) в отличие от 301.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.