Как это сопоставить с интерфейсом RESTful?

Question

Я создаю небольшой инструмент, чтобы помочь людям выбрать групповую деятельность, например, в какой ресторан им следует пойти на обед. Мои объекты - это события, параметры и предпочтения. У события есть несколько опций, пользователь может ранжировать опции по изобретению. Таким образом, голоса пользователей могут быть 1: опция B, 2: опция A, 3: опция C.

Мой вопрос: каков наилучший способ сопоставить это с REST? Кажется очевидным, что я должен поддерживать CRUD для событий с

GET /events/ : list of events
POST /events/ : create a new event
GET /events/1 : get event one
and on options with:
POST /events/1/options : add a new option to the event

(во всех случаях должен быть аутентифицированный пользователь)

Где я запутался, как пользователь голосует заварианты для события. Что лучше всего подходит для REST, так это сделать PUT для каждого варианта, для / events / 1 / options / 1 / голосования, но кажется, что было бы трудно обеспечить соблюдение требований между голосами, например, если бы я хотел принудительноголоса, чтобы оценить варианты без связей, я мог бы сделать это, если бы я получил все голоса сразу, как в 1 B, 2 A, 3 C, но если пользователь меняет свои голоса на 1 C, 2 B, 3 A,приложение будет в недопустимом состоянии между этими запросами.

Должен ли я сделать голоса одним пакетом и получить к ним доступ в / events / 1 / голосах?

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

Answer 1

Поскольку голоса - это записи, которые относятся к пользователю, голосу и варианту, я бы разработал голосование как POST - /votes, по сути, как действие create для этих записей голосования. Тогда вы, очевидно, можете объединить несколько голосов в запрос, который выглядит примерно так, как показано в следующем примере (в json):

POST /votes
[
    { option: 38, vote: 2 },
    { option: 39, vote: 1 },
    { option: 40, vote: 0 }
]

На сервере вы вводите пользователя и возвращаете соответствующий код состояния после проверки целостности.

Answer 2

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

Не ясно, являются ли ваши объекты / event / options, где события имеют набор опций, а операция - «добавить голоса» или модель -a / персона / предпочтения / опция, где предпочтения человека представляют собой заданные опции, и операция аналогична «добавить голоса».

В любом случае ранее предложенная идея размещения POST сразу нескольких опций является правильным подходом RESTFUL, где / person / Preferences или / event являются как собственными наборами опций, так и при работе ссбор, POST является подходящим.

Если бы у вас были пользователи, голосующие по отдельным вариантам, то в обоих случаях вы бы установили счетчик голосов для определенного варианта. В этом случае PUT для / event / option / 1 или / person / preference / 1 (для варианта 1) будет уместным

Answer 3

Я бы сделал это следующим образом:

/events/1/options/vote/1stchoice
/events/1/options/vote/2ndchoice
/events/1/options/vote/3rdchoice
/events/1/options/vote/4thchoice
…

Таким образом, если пользователь хочет проголосовать за А в качестве своего первого выбора, В в качестве своего второго выбора и т. Д., Он НАБИРАЕТ "А"на / events / 1 / options / голосование / 1-й выбор, «B» на / events / 1 / options / голосование / 2-й выбор и т. д.

Если пользователь хотел изменить свой выбор (скажем, сначала сделать B,Во-вторых), ему нужно будет УДАЛИТЬ свои голоса, а затем повторить.

В опросах, где пользователи могут выбрать только один вариант, будет включена только options/vote/1stchoice.