Какой ресурс я должен использовать, чтобы сохранить мой API RESTFul?

Я создаю API, чтобы позволить клиенту API отправлять уведомления, чтобы напомнить пользователю обновить статус заказа. Пока есть два уведомления:

  • когда пользователь не пометил заказ как полученный;
  • когда пользователь не пометил заказ как выполненный.

Я хочу создать этот API, чтобы упростить его распространение на другие уведомления, связанные с заказом, но сохранить простой URI для клиентов этого API. Как я могу определить свои ресурсы, чтобы сохранить мой API RESTFul?

Я думал о том, чтобы иметь одну из этих структур:

Вариант 1:

POST: /api/ordernotification/receive/{id}
POST: /api/ordernotification/complete/{id}

Вариант 2 (пропустите статус ресурса и опубликуйте его):

POST: /api/ordernotification/?id={id}&statusID={statusID}

РЕДАКТИРОВАТЬ

Вариант 2.1 (сохранение сочлененного URI, как предложено @Jazimov):

POST: /api/ordernotification/{statusID}/{id}.

Какой вариант больше подходит? Есть ли какое-то преимущество у одного варианта над другим? Или есть другой вариант, о котором я не подумал?

Источник

3 ответа

Решение

Я хотел бы пойти с чем-то по этим направлениям

POST /api/order/1234/notifications/not-received
POST /api/order/1234/notifications/not-completed

К которым позже можно получить доступ через

GET /api/order/1234/notifications/not-received
GET /api/order/1234/notifications/not-completed

Или же

GET /api/order/1234/notification/8899

Нет никакого реального ограничения семантически богатого URI, так что вы также можете воспользоваться этим и быть явным.

Источник

Если я вас правильно понимаю, у вас есть два типа ordernotifications: для уведомления receive и те, для уведомления complete, Если это две отдельные модели данных, то я думаю, что их вложение - хорошая идея (т. Е. Таблица с именем ReceiveOrderNotification а также CompleteOrderNotification). Если это так, то вы можете полностью раскрыть две разные конечные точки, такие как POST /api/receiveordernotification а также POST /api/completeordernotification,

Но я не думаю, что это лучшее, что вы можете сделать, учитывая, что между уведомлениями о заказах, вероятно, есть много общего. Теперь вариант 2 больше похож на GET, так как вы используете параметры запроса, поэтому с вашей первой опцией давайте свернем их в это:

POST: /api/ordernotification/

а затем передать ему некоторые данные JSON для создания уведомлений

{
    "orderId": "orderId",
    "userId": "userId",
    "prompt": "not marked received/not marked done"
}

Я также удалил /{id} потому что когда ты POST Обычно вы создаете новую вещь, а идентификатор еще не создан. Даже если клиент создает id и отправляя его в API, рекомендуется оставить его открытым, чтобы ваш API мог по-своему создавать новый уникальный ресурс.

Это RESTful, потому что POST создает ресурс ordernotification с определенными точками данных. Ваш первый вариант сделал действия ресурсом самим по себе, но он, вероятно, не представлен ни в одной модели данных в вашем бэкэнде. Чтобы быть максимально RESTful, ваши конечные точки API должны представлять домены базы данных (таблицы, коллекции и т. Д.). Затем вы позволяете своим контроллерам выбирать, какие методы обслуживания использовать, учитывая данные, отправленные в запросе. В противном случае конечные точки REST раскрывают всю логику заранее и становятся длинным списком не поддерживаемых конечных точек.

Источник

Я думаю, чтобы обновить статус уже вставленных записей, ваша конечная точка должна быть PUT вместо POST.

Ты можешь использовать

PUT: /api/ordernotification/:id/status/

с данными клиентов JSON

 {
     "status": "your_status"
 }

согласно данным запроса, конечная точка должна обновить запись.

Источник
Другие вопросы по тегам