url design for RESTful services

У меня есть ресурс под названием Pricing, который я хочу получить. У Offer может быть цена, а Promo может иметь Pricing ресурс и есть другой объект Customer, с которым можно сопоставить Pricing. Я хочу получить Pricing на основе любого из OfferId/PromoId/CustomerId.url design for RESTful services

Для оформления URL-адресов для этого, я бегу в двух вариантах:

Вариант 1: передать его в качестве строки запроса

/pricing?OfferId=234&PromoId=345&CustomerId=543234

Вариант 2: Есть три API,

/pricing/offer?id=234 
/pricing/promo?id=345 
/pricing/customer?id=543234

IMO, OfferId/PromoId/CustomerId следует рассматривать как атрибут ресурса. Поэтому передайте атрибут в качестве строки запроса. Я больше склонен к Варианту 1.

Вариант 2 позволяет избежать еще одного условия для извлечения ресурса и выглядит намного чище, но похоже ли он поддерживает стандарт REST для дизайна URL-адреса?

Каков стандарт REST для разработки URL-адреса. Какой вариант вы бы порекомендовали?

источник

2013-09-25 Pankaj

Я думаю, что общее мнение состоит в том, что вы должны иметь 3 urls going like/prices/offer/1234. См. Пример http://code.msdn.microsoft.com/Build-truly-RESTful-API-194a6253 –

Путь, который будет самым чистым и соответствует стандарту Pathing будет:

/pricing/offer/234 
/pricing/promo/345 
/pricing/customer/543234

С макете существа: /pricing/${offer|promo|customer|/${PathParamForId}

Что вы могли бы сделать, как три отдельных методов одной для предложения/промо /клиент.

Затем вы должны убедиться, что ваш API хорошо документирован, чтобы пользователи знали ожидаемое поведение для путей. (Разница между предложением против промо-поиска и т.д.)

источник

2013-09-26 01:45:10 Welsh

Однако из самого URL-адреса кажется, что мы получаем предложение/промо/клиент вместо цены –

Если вы не рассматривайте его как «мы получаем оценку для категории предложения/промо/клиента с идентификатором X». Необходимо будет узнать больше о том, как объекты выложены/хранятся и бизнес-логика, чтобы знать оптимальную структуру и что необходимо. В любом случае это не должно быть использование Query Params, а скорее Path Params. – Welsh

У меня также такое же мнение, как @AdrianShum. В случае варианта 1 он сам объясняет, что он получает ресурс ценообразования на основе определенных критериев, где, как и в случае варианта 2, мы должны будем сообщить читателю, чтобы прочитать его в определенном контексте, как это было предложено вами. Почему вы не в пользу использования параметров запроса? – Pankaj

Я предпочитаю Вариант 1.
Опция 2 имеет следующие недостатки:

это может запутать пользователей. например, /pricing/offer/234, как представляется, представляют собой ресурс Offer, а не ресурс Pricing.
в бизнес-логике, Offer ресурс содержит Pricing, но /pricing/offer/234 представляют собой прямо противоположный путь. Кажется как Pricing ресурс содержит ресурс Offer.

Фактически, Вариант 1 имеет некоторые проблемы. например,

/pricing?OfferId=234&PromoId=345&CustomerId=543234

получит три значения, не так ли? Кажется

/pricings?OfferId=234&PromoId=345&CustomerId=543234

более разумно.

Другой вариант, вы можете думать о том, Вариант 3:

/offer/234/pricing 
/promo/345/pricing 
/cusomer/543234/pricing

надеюсь, что это полезно.

источник

2013-09-26 03:03:40 Freedom

Это уже предложено @Freedom, но я думаю, что он заслуживает собственного ответа и рассуждений.

Вы хотите получить ценообразование - но это не значит, что вам нужно начинать с него URL pricing.

Promo, Offer и Customer выглядят как ресурсы. Вероятно, у них есть свои собственные URL-адреса, например offer/123. Даже если у них нет URL-адресов, они все еще кажутся логическим элементом контейнера/композиции в Pricing. Таким образом, Pricing должен быть под-ресурсом этих.

/offers/234/pricing 
/promos/345/pricing 
/customers/543234/pricing

Если ценообразование имеет свой собственный идентификатор, что и вы все еще можете добавить дополнительный способ перечислить все ценообразования или получить их к этому ID:

/pricings 
/pricings/12

источник

2015-03-27 18:07:29 Kapep

url design for RESTful services

ответ

Смежные вопросы