Выбор варианта ответа#

Как ответ получает один типизированный исход?

Responses рассматривает ответ как набор объявленных успешных и ошибочных вариантов. Сначала он отбирает кандидатов по статусу, типу данных и условию when, затем читает тело только через их парсеры или экстракторы (eazy_sdk.response.cases).

        flowchart TD
    Response["NormalizedResponse"] --> Filter["Статус + media type + when"]
    Filter -->|нет кандидатов| Fallback["Fallback или Unexpected"]
    Filter --> Parse["Извлечь и разобрать тело"]
    Parse --> Accept["accept или теги модели"]
    Accept --> Rank["Выбрать самый специфичный case"]
    Rank --> Success["SuccessOutcome"]
    Rank --> Error["ErrorOutcome"]
    Rank --> Ambiguous["AmbiguousResponseOutcome"]
    Parse --> Malformed["MalformedOutcome"]

Приоритет вариантов#

Если тело приняли несколько вариантов, побеждает более узкое объявление. Порядок сравнения:

  1. Вариант с критерием перед вариантом без критерия. Критерий задают when=, accept=, Const(...) на поле модели и Location(...) на поле, которое не допускает None.

  2. Точный статус перед диапазоном, диапазон перед DEFAULT.

  3. Точный тип данных перед шаблоном, шаблон перед отсутствующим ограничением.

  4. Операция перед сервисом, сервис перед клиентом.

Полное равенство остаётся неоднозначностью, потому что декларация не даёт основания выбрать один вариант (_most_specific).

ResponseContext лениво предоставляет байты, текст, JSON, заголовки и cookies. Один разобранный артефакт кешируется и используется всеми конкурирующими вариантами ответа (ResponseContext).

Статус перехода, на который операция объявила вариант, принадлежит операции: Responses.declares(status) отвечает исполнителю, и тот не следует Location сам. Запасной вариант fallback= статус не объявляет.

unwrap() успешного исхода возвращает значение. Ошибочный исход создаёт объявленный ApiError, а неожиданный, повреждённый и неоднозначный ответы получают отдельные типы ошибок (ResponseOutcome).

Дальше#