Зачем использовать DELETE/POST вместо PUT для "отмены подписки / подписки" на пользователя?

Question

Ссылка на этот учебник / объяснение API: https://thinkster.io/tutorials/design-a-robust-json-api/getting-and-setting-user-data

В руководстве объясняется, что для "следования за пользователем" вы должны использовать:

POST /api/profiles/:username/follow,

Чтобы "отписаться от пользователя", вы должны использовать:

DELETE /api/profiles/:username/follow,

Профиль пользователя изначально обладает полем "following": false,

Я не понимаю, почему поле "следующее" создается / удаляется (POST/DELETE), а не обновляется из true в false, Мне кажется, что я не понимаю, что на самом деле происходит - разве мы не просто переключаем значение "следования" между true а также false?

Спасибо!

Answer 1

Использование microPUT, безусловно, будет разумной альтернативой. Я не думаю, что кто-нибудь сможет рассказать вам, почему случайное руководство по API приняло определенные дизайнерские решения. Возможно, им просто нужен надуманный пример для использования POST/DELETE.

Если автор не видит этот вопрос, я ожидаю, что он не отвечает. Возможно, что они хотят хранить метаинформацию, такую ​​как отметка времени последующего изменения состояния, но это не будет зависеть от POST / DELETE против PUT.

Answer 2

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

Учитывая, что у вас есть три пользователя, что это будет означать, что один из пользователей имеет "following": true? Этот пользователь следит за чем-то? Одно это не может означать, что пользователь следует за всеми другими пользователями, верно?

Уровень базы данных, вероятно, состоит из (как минимум) двух разных концепций: пользователей и последователей; пользователи содержат информацию о пользователе, а следующие указывают, какие пользователи следуют друг за другом.

Скажем, у нас есть два пользователя:

[
  {"username": "jake"},
  {"username": "jane"}
]

И мы хотим сказать, что Джейн следует за Джейком, но не наоборот.

Тогда нам нужно что-то, чтобы представить эту концепцию. Давайте назовем это следующим:

{"follower": "jane", "followee": "jake"}

Когда API говорит о создании или удалении подписок, это, вероятно, то, что, по их мнению, создается. Вот почему они используют POST/DELETE вместо PUT. Они не изменяют пользовательский объект, они создают другие объекты, которые представляют следующие.

Причина, по которой они "following": true/false часть их ответа JSON API заключается в том, что, когда вы запрашиваете информацию о конкретном пользователе, как об одном из других пользователей, вы хотите знать, следует ли вам как пользователь за этим конкретным пользователем.

Итак, учитывая приведенный выше пример, когда Джейн будет запрашивать информацию о Джейке, в GET /api/profiles/jakeона получит что-то вроде этого:

{
  "profile": {
    "username": "jake",
    "bio": "...",
    "image": "...",
    "following": true
  }
}

Однако, когда Джейк будет запрашивать информацию о профиле Джейн, он получит такой ответ:

{
  "profile": {
    "username": "jane",
    "bio": "...",
    "image": "...",
    "following": false
  }
}

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