REST API: правильно запрашивать действие

В настоящее время я работаю над REST API. Я несколько раз читал, как правильно обращаться с конечными точками, используя протокол (отправить, поставить, ...), чтобы определить, какое действие следует выполнить.

Допустим, у меня есть список цитат. У меня есть :

  • конечная точка GET /quotes, которая позволяет мне получить все мои котировки
  • POST /quote для размещения новой цитаты
  • GET /quotes/ID для получения одной цитаты
  • PUT /quote/ID для обновления цитаты.

Теперь я хочу добавить возможность:

  • поделиться цитатой с другим участником
  • отметить цитату как любимую
  • снять отметку

Какую конечную точку я должен использовать для этого? /quote/ID/share кажется ужасной идеей. Я подумал о POST для /quote/ID с параметром «действие», который сообщает сценарию, какое действие выполнять над цитатой, будет ли это правильно?


api rest endpoint
person Jeremy Belolo    schedule 22.06.2015    source источник
comment
Как действует? Пожалуйста, опишите, что такое член. Являются ли члены REST ресурсами?   -  person    schedule 22.06.2015

Ответы (1)


arrow_upward
1
arrow_downward

Попробуйте отделить API от логики вашего приложения. Из API вы ПОЛУЧАЕТЕ котировку, и API теперь не должно заботиться о том, что вы делаете с этими данными. То же самое с пометкой цитат как избранных. Это проблема вашего приложения и пользователя db, как что-то пометить. Опять же, API должен заботиться только о правильном ответе на ваши GET.

Думайте о REST API как о базе данных — вы ПОЛУЧАЕТЕ данные оттуда, вы можете PUT или POST некоторые данные, но такие вещи, как совместное использование или маркировка, должны выполняться в приложении.

Изменить

О конечных точках.

  • GET/POST/PUT /quote[s] должен заботиться только о кавычках;
  • PUT/POST /user/{userId}/action с данными POST типа {"type": "share", "target": "otherUserId", "quoteId": 123} можно использовать для сохранения данных о действиях в БД.
person kaaposc    schedule 22.06.2015
comment
Не могли бы вы подробнее рассказать? - person Mehdi; 22.06.2015
comment
@mef, мне подробнее? - person kaaposc; 22.06.2015
comment
Я думаю, было бы полезно привести примеры конечных точек, которые он может использовать для своего конкретного случая использования. - person Mehdi; 22.06.2015
comment
Эй, и спасибо за ваш ответ! Конечно, совместное использование, как вы думаете о совместном использовании с друзьями в Facebook, является клиентской стороной, но это не то, о чем я думал: у меня есть таблица, связывающая цитаты с пользователями, и пользователи могут отправлять цитаты другим пользователям в своем списке друзей, создавая запись в базе данных. То же самое справедливо и для пометки как избранного, это обновляет запись в базе данных. Поэтому мне нужен сервер, чтобы позаботиться об этом, и поэтому маршрут для вызова, чтобы сообщить ему, чтобы позаботиться об этом. - person Jeremy Belolo; 22.06.2015
comment
Почему бы не создавать акции как юридические лица? - person Opal; 22.06.2015
comment
Спасибо за улучшенный ответ. Я действительно хотел бы знать, почему вы используете конечную точку /users вместо /quotes, поскольку это применимо только к кавычкам, и мне абсолютно не нужно, чтобы мой идентификатор пользователя был частью конечной точки (пользователь уже идентифицирован с помощью Оаут2). Не было бы более правильным использовать конечную точку /quotes, как я предложил, возможно, с /action в конце, как вы сделали в своем ответе? - person Jeremy Belolo; 22.06.2015
comment
Цитаты похожи на книги в библиотеке — их можно ПОЛУЧИТЬ, может быть, даже внести некоторые правки (пометки POST карандашом, что-то плохое), но вы не храните информацию о читателях книг в книге. Вам лучше выбрать отдельный объект, как предложил @Opal - что-то вроде статистики или некоторых других метаданных. - person kaaposc; 22.06.2015