REST API - добавление элемента в качестве реляционного ресурса к другому ресурсу

Question

Мне было интересно, что будет лучшим подходом при добавлении ресурса, связанного с другим ресурсом.

У меня есть два объекта: + Сотрудник: сотрудник ИТ-компании + Навыки: набор сотрудниковтехнологических навыков;например, Java.

Кто-то может создать сотрудника через REST по следующему пути:
POST: /employee

Хотя кто-то может создать объект Skill сам по себе, аналогично созданиюEmployee объект, но он должен быть связан с Employee, таким образом ...

PATCH: /employee/{employeeId}/skill

Этот путь создаст новый Skill для Employee объект, но здесь я задаюсь вопросом, если я делаю что-то не так.

Обычно, когда вы создаете новый ресурс, вы используете глагол POST, но в то же время я также обновляю часть ресурса Employee, таким образом, он действует как глагол PATCH. Кроме того, у глагола POST не должно быть таких параметров, как {employeeId}.

Каков наилучший подход / практика при документировании REST API с этим сценарием?

Answer 1

Каков наилучший подход / практика при документировании REST API с этим сценарием?

Возможно, стоит рассмотреть доклад Джима Уэббера 2011 года. ;короче говоря, если вы выполняете REST, то вы передаете документы - полезная работа, выполняемая для вашей доменной модели, - это побочный эффект манипулирования документами.

Если вы используете PUT / PATCH, тогда вы в основном выполняете удаленную авторизацию - то есть вы просите сервер принять вашу локальную копию документа. И это прекрасно , даже когда сервер, принимая ваши изменения, также будет изменять свое представление других ресурсов.

Вместо этого вы могли бы спроектировать протокол домена приложения, чтобы сделать удаленнымредактирует документ сотрудника напрямую или даже POST -ing редактирует этот ресурс, что, в свою очередь, может иметь побочные эффекты для ресурса навыка.

Помните, первое приложение, разработанное с использованием архитектурного стиля REST, былоВсемирная сеть;наиболее распространенным типом мультимедиа для определения протоколов доменных приложений был HTML, а единственным небезопасным методом запроса, изначально поддерживаемым HTML, был POST - и это было катастрофически успешно.

Так что POST равно отлично .

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