Какой HTTP-глагол наиболее подходит для добавления / удаления отношения «многие ко многим»?

Question

Предположим, две таблицы в реляционной базе данных A & B и таблица соединения C. Таблица соединения пуста, пока отношения не будут добавлены явно.

Я выставляю конечные точки REST для добавления / удаления этих отношений (добавить / удалить запись в таблице C). Они не изменяют записи в таблице A или B, но с точки зрения потребителя связь A с B так же важна, как и сами объекты. будет чувствовать , как будто ресурс изменяется. Но на самом деле происходит добавление / удаление строки из таблицы C.

Какой глагол (ы) будет наиболее подходящим для добавления / удаления конечных точек? POST / DELETE? PUT / PUT? Для PATCH может быть даже рассмотрен случай (если я выберу «измененный» маршрут, я не заменяю весь ресурс, только его часть)

ОБНОВЛЕНИЕ: Я наблюдаю похожие ситуации, возникающие при создании нового ресурса (/ api / friendships / create | delete). Если это в конечном итоге является ответом, пусть будет так, но отношения в моем случае больше похожи на список воспроизведения , добавляемый / удаляемый из библиотеки

Answer 1

Какой глагол (ы) будет наиболее подходящим для добавления / удаления конечных точек?

Как бы вы сделали это с веб-сайтом?

Клиент, вероятно, загрузит какую-то форму - он может иметь список A и список B, или он может принять определенный A и просто предоставить список B. Пользователь может сделать свой выбор из вариантов в форме и отправить его.

Так как это не безопасный , вы, вероятно, указали бы, что метод в форме: POST .

Если клиент знает, как должно выглядеть представление конечной точки взаимосвязи, и знает, какой URI следует использовать для ресурса взаимосвязи, тогда PUT может быть уместным - в этот момент вы эффективно делает удаленный авторинг.

Answer 2

Поскольку отношения являются гражданами первого сорта, соответствующими глаголами будут POST и DELETE (или PUT и DELETE, если отношения не могут быть дублированы, т.е. если для каждой пары A-B может существовать только одно отношение). В API RESTful HTTP-глаголы обычно более точно соответствуют намерениям потребителя, чем подробности реализации сервера (которые не касаются потребителя).