Должны ли микросервисы точно следовать HTTP-глаголам?

Должны ли микросервисы точно следовать HTTP-глаголам?
Должны ли микросервисы точно следовать HTTP-глаголам? - growtika @ Unsplash

Меня беспокоит практика моей команды в отношении точного следования глаголам REST и HTTP. Например, когда мы попадаем в конечную точку получения несуществующего ресурса/ресурсов, мы возвращаем 404. Разве мы не должны возвращать пустой список с 200? Я думал, что 404 зарезервирован для несуществующего URL. Точно ли ваша организация следует принципам REST? И насколько это большая проблема? Я чувствую, что большинство организаций, которые исповедуют REST, в конечном итоге переходят на RPC.

Должны ли микросервисы точно следовать глаголам HTTP?

Да.

насколько это серьезная проблема?

Это будет зависеть от ряда вещей, включая то, сколько различных организаций взаимодействуют с вашим микросервисом через этот API, и сколько компонентов общего назначения вы собираетесь внедрить.

Интерфейс REST разработан для эффективной передачи данных гипермедиа большого объема, оптимизирован для общего случая Web, но в результате получился интерфейс, который не является оптимальным для других форм архитектурного взаимодействия. -- Филдинг, 2000

Когда ваш микросервис не нуждается в "веб-масштабировании", когда клиенты и серверы находятся под общим контролем и могут координировать релизы, тогда доводы в пользу точности начинают больше склоняться к "лучшим практикам", чем к последствиям.

Например, когда мы попадаем в конечную точку get для несуществующего ресурса/ресурсов, мы возвращаем 404. Разве мы не должны возвращать пустой список с помощью 200? Я думал, что 404 зарезервирован для несуществующего URL.

У REST нет конечных точек, только ресурсы ( Fielding, 2018 ).

Смысл сообщения 404 стандартизирован:

Код состояния 404 (Not Found) указывает на то, что сервер происхождения не нашел текущего представления для целевого ресурса или не желает раскрывать информацию о его существовании.

Что не стандартизировано: любые ограничения реализации на то, что определяет "текущее представление".

Это означает, что при определении модели ресурсов вы сами решаете, когда "ресурс" имеет текущее представление, а когда нет. То есть, именно вам решать, является ли тело ответа представлением ресурса, или вместо этого оно является представлением ошибки клиента.


Например, когда я запрашиваю у Google текущее представление ресурса

https://www.google.com/search?q=250699d1-6711-4592-9d35-9643f1fb9cc2

Ответ, возвращенный мне, имеет код состояния 200, поэтому я знаю, что тело ответа является представлением этого ресурса (то есть это документ, описывающий, какие страницы в индексе Google соответствуют данному конкретному запросу).

Человекочитаемый текст в этом HTML-документе выглядит следующим образом

Your search - 250699d1-6711-4592-9d35-9643f1fb9cc2 - did not match any documents.

И это нормально. Но для Google было бы не менее правильно вместо этого вернуть ответ с ошибкой клиента, если бы он хотел утверждать, что не существует ресурса, соответствующего указанному мной запросу-цели.

HTTP не ограничивает реализацию в выборе ответов для отправки; он ограничивает только семантику этих сообщений.


LetsCodeIt, 17 декабря 2022 г., 20:03