Должна ли модель полезной нагрузки RESTful API определять, как должен вести себя api? - PullRequest
Новая
       181

Должна ли модель полезной нагрузки RESTful API определять, как должен вести себя api?

0 голосов
/ 19 июня 2020

Допустим, у меня есть объект задачи, смоделированный в моем приложении как { id: "qweqdsad", name:"Drink Coffee", description:"Coffee helps in overcoming laziness", userId:12 }

Теперь в моем приложении, скажем, JSON является полезной нагрузкой для создания конечной точки задачи. В этом случае, если я должен предотвратить Пользователь не может добавлять или создавать задачи другим пользователям, кроме него. Если полезная нагрузка api смоделирована как { id: "qweqdsad", name:"Drink Coffee", description:"Coffee helps in overcoming laziness" }

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

Проще говоря, должно Я переделываю структуру своей сущности на основе функциональности или авторизации?

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

1 Ответ

0 голосов
/ 19 июня 2020

Следует понимать, что HTTP ограничивает семантику сообщений - что сообщения означают - но не ограничивает реализацию сервера. См. Замечания Филдинга 2002 г. о «безопасном».

Итак, если вы должны были отправить запрос, например, 

PUT /977215bc-80f9-43f5-b95b-bff5be20ca71 HTTP/1.1
Content-Type: application/json

{
  id: "qweqdsad",
  name:"Drink Coffee", 
  description:"Coffee helps in overcoming laziness"
}

Сервер может изменить это представление при необходимости . Спецификация PUT фактически вызывает это

Исходный сервер НЕ ДОЛЖЕН отправлять поле заголовка валидатора (раздел 7.2), такое как поле ETag или Last-Modified, в успешный ответ на PUT, если данные представления запроса не были сохранены без какого-либо преобразования, примененного к телу (т. е. новые данные представления ресурса идентичны данным представления, полученным в запросе PUT), а значение поля валидатора отражает новое представление. Это требование позволяет пользовательскому агенту знать, когда тело представления, которое он имеет в памяти, остается текущим в результате PUT, таким образом, не нуждается в повторном получении с исходного сервера, и что новый валидатор (-ы), полученный в ответе может использоваться для будущих условных запросов, чтобы предотвратить случайную перезапись

...