HTTP RESPONSE, когда переменная пути пуста в методе PUT - PullRequest
Новая
       50

HTTP RESPONSE, когда переменная пути пуста в методе PUT

1 голос
/ 26 февраля 2020

Я пытаюсь найти лучшую практику о том, какой тип ответа я должен отправлять, когда параметр пути в REST-сервисе пуст или равен нулю при использовании метода PUT.

Например, представьте, что у нас есть следующий ресурс:

PUT отчет / {идентификатор_отчета} / клиент / {идентификатор_предприятия}

Должен ли я проверить, что параметр report-id и client- id не пустые или пустые?

Если они пустые или пустые, я могу представить два типа сообщений:

  • Возвращать ответ 400 с сообщением, указывающим, что обязательный параметр отсутствует.
  • Возвращает ответ 404, указывающий, что мы не можем создать или обновить ресурс, потому что этот ресурс не существует?

Я не думаю, что есть стандарт условность делать это. Есть? Тем не менее, я хотел бы услышать мнения о том, что лучше использовать в этом случае.

Ответы [ 2 ]

0 голосов
/ 26 февраля 2020

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

Важно понимать, что тело ответа доступно вам для подробного описания реальной проблемы. См. RF C 7231, раздел 6.5

, серверу СЛЕДУЕТ отправить представление, содержащее объяснение ситуации с ошибкой, а также является ли это временным или постоянным условием.

Код состояния - это метаданные, которые позволяют компонентам общего назначения понять, что происходит. Все метаданные принадлежат унифицированному интерфейсу, то есть домену «передачи документов по сети».

В этом случае, я думаю, вам лучше всего подходит код состояния 403 Запрещено

Код состояния 403 (Запрещено) указывает, что сервер понял запрос, но отказывается его авторизовать.

0 голосов
/ 26 февраля 2020

Спецификация для REST может быть полезной:

Ключевая абстракция информации в REST - это ресурс. Любая информация, которая может быть названа, может быть ресурсом: документ или изображение, временная служба (например, «сегодняшняя погода в Лос-Анджелесе»), набор других ресурсов, не виртуальный объект (например, человек) и т. Д. , Другими словами, любая концепция, которая может быть целью гипертекстовой ссылки автора, должна вписываться в определение ресурса. Ресурс - это концептуальное сопоставление с набором сущностей, а не сущность, которая соответствует сопоставлению в любой конкретный момент времени.

Поскольку отсутствие ресурса не может логически дать ему имя, оно может никогда не существует в REST. Как следствие, я думаю, что вы обнаружите, что большинство публикуемых c API вернут 404. Взять, к примеру, получение информации о пользователе от GitHub. В документации говорится, что пользователь может быть найден на https://api.github.com/users/{username}. https://api.github.com/users/ (обратите внимание на конечный пункт sh) возвращает 404. Независимо от того, что говорит HTTP spe c (хотя придерживаться его - всегда хорошая идея), если вы придерживаетесь принципа наименьшего удивления возврат 404 - ваш лучший выбор.

В качестве примечания, при именовании ресурсов принято, что коллекции должны быть множественными. Итак, для вашего примера вы бы действительно хотели, чтобы ресурс выглядел так: /reports/{report-id}/clients/{client-id}. Особенно, когда имеешь дело с «пустыми» параметрами, это будет намного более точно определять, для чего был сделан запрос.

...