Должен ли я быть допускающим неизвестных параметров?

Я проектирую RESTful API и столкнулся с проблемой заголовка, для ясности:

Должен ли я быстро потерпеть неудачу, если клиент отправляет нераспознанный параметр? Например,

http://example.com/api/foo?bar=true&paula=bean

Выше указан barдопустимый параметр, но paulaон не указан API. Нужно ли мне

Предупредить клиента об ошибке
Терпеть неудачу быстро
Игнорируй это

Если я предупреждаю клиента, я могу выдать предупреждение только для первого параметра, поскольку он может отправлять почти бесконечное число из них, и у сервера, вероятно, есть более важные задачи. Точно так же, при сбое, он будет указывать только первый неверный параметр в качестве проблемы.

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

Мои аргументы имеют смысл? Есть ли принятая практика на такие вещи?

rest api-design

— Рат
источник

Основываясь на небольшом тесте, все сайты, которые я тестировал, просто игнорируют неизвестные параметры, которые я им предоставил.

— Барт ван Инген Шенау

@BartvanIngenSchenau То же самое здесь. Это хорошо для веб-страниц, но я не думаю, что это нормально для реального API

— rath

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

— Walpen

@walpen Это интересный момент. Использование версионных URL-адресов api/v1и т. Д. Позаботится об этом, но все равно не допускает дополнительных обновлений. +1

— Рат

Там вы можете найти некоторые плюсы и минусы с реальной точки зрения: строгие параметры и ваш API .

— Ремек Амброзиак

Ответы:

По моему мнению, вы должны вернуть статус Invalid Request, чтобы клиент знал, что то, что он пытается сделать, недопустимо. Мое мнение об этом зависит от концепции, что API-интерфейсы RESTful являются обнаруживаемыми . Если вы предоставляете достаточно информации заранее, то клиент никогда не пытается сделать неверный запрос с самого начала. Если это так, то в коде клиента что-то не так, и быстрый сбой предупредит секунду об этой ошибке. Конечно, это очень пуристический подход, и его нельзя рекомендовать, если ваш API не доступен для обнаружения.

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

— Резиновая утка
источник

Как расширение: если клиент отправляет некоторые неизвестные / только для чтения / устаревшие параметры, это означает, что клиент ожидает некоторого поведения, которое не будет выполнено. И поэтому опасно выполнять какие-либо действия. Так что я согласен, строго плохая просьба

— Степан Степанов

Спасибо @StepanStepanov, но есть философия «будь терпелив в том, что ты принимаешь, прямо в том, что ты посылаешь», лежащая в основе большей части веб-архитектуры. Имея это в виду, я мог бы легко написать ответ, прямо противоположный тому, который я уже написал.

— RubberDuck

Я гуглил это)) И на странице о законе Постеля также написано, что «код, который получает ввод, должен принимать неконформный ввод, если смысл понятен». Я думаю, что если клиент отправит нам какой-то неизвестный параметр, его значение не может быть ясным. Если клиент отправляет нам устаревший параметр, это ясно, он не будет работать, как прежде, и так, как ожидает клиент. Если клиент отправит нам параметр только для чтения, это ясно, он будет записан не так, как хочет клиент.

— Степан Степанов

Если вы используете открытый API (или API, который будет использоваться другой командой), я бы порекомендовал вернуть ошибку, как предложено @RubberDuck.

Если ваш API будет использоваться только внутри вашей команды (или только вами), возможно, будет легче игнорировать дополнительные поля (например, требуется меньше кода и легче сделать).

— Константин Петрухнов
источник