#rest #specifications
#rest #технические характеристики
Вопрос:
Допустим, у нас есть следующий API:
GET /api/colors/{color}
GET /api/integers/{number}
В коде я ожидаю, что ‘color’ будет соответствовать некоторому значению в enum, а ‘number’ — целое число.
Например:
GET /api/colors/red
GET /api/integers/2
будет отвечать HTTP 200.
Но тогда как я должен отвечать на такие запросы, как:
GET /api/colors/foo
GET /api/integers/bar
Должно ли оно быть 404, потому что color ‘foo’ и integer ‘bar’ не существуют? Или 400, потому что клиент не использовал некоторые согласованные допустимые значения (перечисление, целое число)?
Ответ №1:
Ресурс, отвечающий на 404 запрос, может 200 появиться позже.
Например, вы запрашиваете цвет, который недоступен на сегодняшний день, но может быть добавлен завтра:
GET /api/colors/lightblue
Должен отвечать 404 .
В то время как запрос like /api/integers/bar неверно сформирован и будет искажен в будущем, поэтому он должен отвечать 400 ; целое число семантически никогда не может быть строкой.
Отправка 400 сообщает клиенту «не запрашивать это снова», клиент может «запомнить» (кэшировать) этот ответ неявно.
404 сообщает клиенту: «Прямо сейчас у меня нет того, что вы запрашиваете, повторите попытку позже». Клиент может применять кэширование на основе эвристики или явно.
Комментарии:
1.
/api/integers/barмое приложение может считаться искаженным, но по стандартам оно полностью допустимо. Нормально ли, что разные API по-разному понимают, что такое неправильный uri?2. @Valdemaras Возможно, искаженный — неправильное слово. Это допустимый URI, но в отношении семантики вашего API он недействителен. Стандарта нет, только лучшие практики. Многие из вопросов, подобных вашему, закрываются, потому что ответ — это мнение, а не стандарт.
3. @DansFromGermany Я думаю, вы правы, что это вопрос мнения. С самого начала просто не ясно, что для этого нет никакого стандарта: (
Ответ №2:
Должно ли оно быть 404, потому что color ‘foo’ и integer ‘bar’ не существуют?
404.
Все коды состояния 4xx сообщают клиенту, что с запросом возникла какая-то проблема. Семантическое различие заключается 404 в том, что намекает на орфографическую ошибку в целевом uri.
Одна из причин, по которой мы заботимся: 404 кэшируется; универсальные компоненты могут запоминать ответ на запрос и сохранять обратную передачу на сервер, если запрос повторяется.