REST-способ проверки / снятия отметки как / в отличие от избранного / нежелательного ресурса

Question

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

Моя модель «Мне нравится» (это приложение на Ruby on Rails 3) полиморфна и принадлежит двум разным ресурсам:

/api/v1/resource-a/:id/likes

и

/api/v1/resource-a/:resource_a_id/resource-b/:id/likes

Дело в том, что я сомневаюсь, какой способ выбрать, чтобы сделать мои ресурсы максимально RESTful. Я уже попробовал следующие два способа реализовать структуру "как / не нравится" в моих URL:

Случай A: (похоже / не похоже на членство в «ресурсе»)

PUT /api/v1/resource/:id/like maps to Api::V1::ResourceController#like
PUT /api/v1/resource/:id/unlike maps to Api::V1::ResourceController#unlike

и случай B: ("лайки" - это отдельный ресурс)

POST /api/v1/resource/:id/likes maps to Api::V1::LikesController#create
DELETE /api/v1/resource/:id/likes maps to Api::V1::LikesController#destroy

В обоих случаях у меня уже есть сеанс пользователя, поэтому мне не нужно указывать идентификатор соответствующей записи "like" при удалении / "unliking".

Я хотел бы знать, как вы, ребята, реализовали такие случаи!

Обновление от 15 апреля 2011 года: Под «сессией» я имею в виду заголовок базовой аутентификации HTTP, отправляемый с каждым запросом и предоставляющий зашифрованную комбинацию имени пользователя и пароля.

Answer 1

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

В случае A вы указали URI для операций, что опять-таки не RESTful. URI идентифицируют ресурсы, и переходы между состояниями должны выполняться с использованием единого интерфейса, который является общим для всех ресурсов. Я думаю, что Дело B намного лучше в этом отношении.

Итак, имея в виду эти две вещи, я бы предложил что-то вроде:

PUT /api/v1/resource/:id/likes/:userid
DELETE /api/v1/resource/:id/likes/:userid

У нас также есть дополнительное преимущество в том, что пользователь может зарегистрировать только одно «Мне нравится» (они могут повторять это «Мне нравится» столько раз, сколько ему хочется, и, поскольку PUT является идемпотентом, он имеет один и тот же результат, независимо от того, как много раз это выполнялось). DELETE также идемпотентен, поэтому, если операция «В отличие» повторяется много раз по какой-то причине, система остается в согласованном состоянии. Конечно, вы можете реализовать POST таким образом, но если мы используем PUT и DELETE, мы увидим, что правила, связанные с этими глаголами, похоже, действительно хорошо подходят для нашего варианта использования.

Я также могу представить еще один полезный запрос:

GET /api/v1/resource/:id/likes/:userid

Это вернуло бы детали «Like», такие как дата, когда было сделано, или порядковый номер (то есть «Это был 50-й подобный!»).

Answer 2

вариант B лучше, и вот хороший пример из GitHub API.

1. Начните репо

   PUT /пользователь / помеченный /: владелец /: репо

2. снять репо

   УДАЛИТЬ / пользователь / помечен /: владелец/: репо

Answer 3

Вы фактически определяете «похожий» ресурс, факт, что пользовательский ресурс любит какой-то другой ресурс в вашей системе.Поэтому в REST вам нужно выбрать схему имени ресурса, которая однозначно идентифицирует этот факт.Я бы предложил (используя песни в качестве примера):

/like/user/{user-id}/song/{song-id}

Затем PUT устанавливает симпатию, а DELETE удаляет ее.GET конечно узнает, нравится ли кому-то определенная песня.И вы можете определить GET /like/user/{user-id}, чтобы увидеть список песен, которые нравятся конкретному пользователю, и GET /like/song/{song-id}, чтобы увидеть список пользователей, которым нравится определенная песня.

Если вы предполагаете, что имя пользователя установленов существующем сеансе, как указывает @joelittlejohn, и он не является частью имени подобного ресурса, тогда вы нарушаете ограничение безгражданства REST и теряете некоторые очень важные преимущества.Например, пользователь может получать только свои лайки, а не лайки своих друзей.Кроме того, это нарушает HTTP-кеширование, поскольку лайки одного пользователя неотличимы от лайков другого.