Какой соответствующий код статуса HTTP использовать в этом сценарии?

Question

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

изображение, демонстрирующее поток

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

Мы получаем токен и go до Upstream API 1, получая обратно связка Objects, связанная с этим токеном. Теоретически может быть возвращено неограниченное количество Objects.

Затем мы разделяем идентификаторы каждого Object и go до Upstream API 2 с разделенными запятыми ObjectIDs, чтобы получить далее MetaInformation на всех Objects.

. Этот MetaInformation может быть не уникальным для каждого Object, поэтому мы можем получить в любом месте от 1 до числа Objects MetaInformation назад.

Тогда мы собираемся go к третьему API с разделенной запятой MetaInformationIDs, но этот восходящий API может занять только 10 уникальных MetaInformationIDs, что означает, что мы не сможем собрать информация, которую ожидает клиент. Поэтому мы можем выбросить случай сбоя на этом этапе, не выполняя запрос на сбой восходящего потока, но какой статус HTTP уместно использовать?

Не похоже, что клиент сделал неверный запрос, так как у него не было бы возможности узнать количество уникальных MetaInformationIds на тот момент, но мы получили бы получит 400 статус, в котором мы должны сделать запрос с> 10 MetaInformationIds.

Есть идеи?

РЕДАКТИРОВАТЬ: я забыл упомянуть для контекста, что восходящий API намеревается обновить в в будущем будет поддерживаться> 10 уникальных идентификаторов, поэтому было решено, что пока решение с несколькими запросами для этого API не стоит. Я искренне согласен с тем, что это неоптимальное решение.

Answer 1

Я бы предложил вашему второму микросервису создать пакеты MetaInformationIDs, достаточно малые, чтобы вызов к третьему микросервису был успешным. В этом случае ожидается, что вызовы будут успешными, устраняя описанную вами ошибку. Если вы не можете сделать что-то подобное, то, возможно, вам следует пересмотреть свой дизайн. Если вы можете сделать это, то в качестве запасного варианта вы можете вернуть код ошибки на стороне сервера 500, что означает, что на сервере произошла какая-то общая ошибка.

Answer 2

Если 10+ MetaInformationIDs является плохой / неожиданной ситуацией, то соответствующий код состояния будет 500 Внутренняя ошибка сервера - как вы говорите, проблема не в запросе, а скорее в внутреннее ограничение, которое не может контролироваться клиентом.

Если это не исключительное обстоятельство, то это скорее похоже на ограничение вашего API, к которому необходимо обратиться, например, вместо поддержки одного запроса к 3-му API, создайте достаточно, чтобы охватить все уникальные идентификаторы, которые необходимо обработать и вернуть 202 Принято

Answer 3

Мы используем код состояния ответа 400, чтобы указать, что сервер не может или не будет обрабатывать запрос из-за того, что воспринимается как ошибка клиента (например, синтаксис некорректного запроса), которая не соответствует вашему сценарию.

Код состояния 500, или Внутренняя ошибка сервера, означает, что сервер не может обработать запрос по неизвестной причине. Иногда этот код появляется, когда более конкретные ошибки c 5xx более уместны, что кажется уместным в ваших условиях, поскольку ваш API может принимать только 10 уникальных MetaInformationID.