Параметры нескольких путей по сравнению с параметрами запроса в RESTful API для POST?

Я пытаюсь реализовать спокойный API

У меня есть объект под названием Программа (описание и сведения о местонахождении)

У меня есть объект под названием "Время" (программа + время начала + время окончания)

У меня есть объект под названием Check-In (Время + сведения о пользователе)

Сценарий: мне нужна регистрация на доступное время,

Каким должен быть идеальный URL-адрес для запроса POST, вариант А

POST /programme/:id/timing/:id/check-in
query param: null

Вариант Б

POST /check-in
request body: {programme=id,timing:id}

Первый подход будет точно использовать идентификатор в параметре пути и напрямую идентифицирует ресурс. Во втором подходе потребитель сообщает тип ресурса, в условиях фильтрации упоминает тип ресурса.

Примечание: мы используем UUID для ресурса Program and Timing, что сделает URL-адрес немного большим.


rest api-design restful-url
person Bharathan Kumaran    schedule 16.09.2019    source источник
comment
Не существует такой вещи, как URL-адрес RESTful, и есть запрос , чтобы удалить этот тег. URL-адрес остается URL-адресом, несмотря ни на что. В целом это указатель на определенный ресурс, который предоставляет некоторые произвольные данные. Не следует делать вывод о семантике символов в URL-адресе, поскольку это приводит к типизированные ресурсы. В дополнение к этому REST не имеет ничего общего с api-design.   -  person Roman Vottner    schedule 16.09.2019
comment
Это чисто вопрос мнения.   -  person Jared Smith    schedule 16.09.2019
comment
@RomanVottner, как вы сказали, стандартов может не быть, я хотел знать, как лучше всего / каким-либо способом согласовать требование.   -  person Bharathan Kumaran    schedule 17.09.2019

Ответы (3)


arrow_upward
2
arrow_downward

Если вы идете по пути Restful, то вы хотите идентифицировать подходящие ресурсы и выполнять операции CRUD с этими ресурсами.

Есть 3 ресурса: - Программа - Пользователь - Расписание (Время - плохое имя ресурса для этого) -> принадлежит-> Программа - Регистр-> принадлежит (Пользователь, Расписание)

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

POST / register BODY {user_id: user1, schedule_id: s1}

person Karthik Krishnan    schedule 17.09.2019
comment
Спасибо, что указали правильный подход, я переименовал ресурсы в Sessions вместо времени. Я буду использовать этот подход POST / register BODY {user_id: user1, schedule_id: s1}, за исключением того, что идентификатор пользователя будет частью самого заголовка. - person Bharathan Kumaran; 17.09.2019

arrow_upward
2
arrow_downward

Оба будут работать, но GET больше подходит для запроса информации. Пока ваши URL-адреса меньше 4000 байтов, это не будет проблемой.

person Evert    schedule 16.09.2019
comment
Спасибо за ответ. Мой текущий вариант использования - регистрировать людей на ресурсе хронометража отдельных лиц. В настоящее время в моей модели есть часть ресурса Program для регистрации. Извините, если мой вопрос был непонятен, обновите вопрос сейчас. Спасибо - person Bharathan Kumaran; 16.09.2019

arrow_upward
0
arrow_downward

Кэширование представлений ресурсов является важным аспектом в архитектурный стиль ОТДЫХ.

В HTTP это выражается так: ожидается, что совместимые кеши будут сделать недействительными кэшированное представление ресурса, если мы получаем ответ без ошибки на небезопасный запрос (например, POST). URI - это ключ кэша, и поэтому target-uri запроса POST определяет, какая запись кэша будет удалена.

Поэтому при разработке нашего протокола мы думаем о том, какие ресурсы будут изменены действием, и используем идентификатор ресурса, который будет изменен, в качестве цели, когда мы вносим изменение.

Какие ресурсы нам нужны GET, чтобы увидеть эффект от изменения? Это должно быть целью запроса на изменение.

POST /check-in
request body: {programme=id,timing:id}

Это написание имело бы смысл, если бы GET /check-in было тем, на что вы хотели бы смотреть на клиенте. Судя по вашему описанию, это кажется не совсем правильным - это звучит слишком грубо.

POST /programme/:id/timing/:id/check-in
query param: null

Это, с другой стороны, выглядит слишком мелкозернистым; как если бы кто-то думал, что правильное применение принципа единой ответственности состоит в том, что каждый POST обработчик будет делать ровно одну вещь.

Есть ли check-out, который "идет" с check-in? Если да, то эти запросы, вероятно, отправляются в одно и то же место.

POST /programme/:id/timing/:id

action=check-in

POST /programme/:id/timing/:id

action=check-out

Возможно, именно programme, а не timing, является правильным зерном для вашего домена

POST /programme/:id

action=check-in&timing=:id
person VoiceOfUnreason    schedule 16.09.2019
comment
спасибо за вклад, я разработал ресурс по-другому. Мой новый дизайн будет похож на те же строки POST / register BODY {user_id: user1, time: t1}, предложенные Картиком. - person Bharathan Kumaran; 17.09.2019