Geek Answers Handbook

URL Design for RESTful Services

I have a resource called Pricing that I want to get. Offer can have a price, and Promo can have a Pricing resource and there is another Customer object with which Pricing can be matched. I want to get Pricing based on one of OfferId / PromoId / CustomerId .

To create the urls for this, I have two options:

Option 1: Pass it as a query string

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

Option 2: You have three APIs

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

IMO, OfferId / PromoId / CustomerId should be considered as a resource attribute. Therefore, pass the attribute as a query string. I am more inclined to Option 1.

Option 2 avoids another condition for retrieving the resource and looks much cleaner, but does it seem to support the REST standard for URL design?

What is the REST standard for developing URLs. Which option would you recommend?

+8
java rest
source share
3 answers

What would be the cleanest and fit the standard paths would be the following:

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

When linking: /pricing/${offer|promo|customer|/${PathParamForId}

What could you do as three separate methods, one for a proposal / promo / client.

Then you just need to make sure your API is well documented so that users know the expected behavior for the paths. (The difference between a sentence and prospective search, etc.)

+4
source share

I prefer option 1.
Option 2 has the following defects:

  • this can confuse users. for example, /pricing/offer/234 seems to represent the Offer resource, not the Pricing resource.
  • in business logic, the Offer resource contains Pricing , but /pricing/offer/234 is the other way around. It seems like the Pricing resource contains the Offer resource.

Actually, Option 1 has some problems. eg,

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

will get three Adventures, right? It seems

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

is more reasonable.

Another option you might think of is option 3:

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

Hope this will be helpful.

+5
source share

This has already been suggested by @Freedom , but I think it deserves its own answer and reasoning.

You want to get pricing - but that doesn't mean you need to start pricing URLs with it.

Promo , Offer and Customer look like resources. They probably have their own urls like offer/123 . Even if they don't have URLs, they still seem to be the logical element of the container / composition in pricing . Thus, pricing should be a sub-resource.

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

If the price has its own identifier, you can add an additional way to list all prices or get them by this identifier:

 /pricings /pricings/12
0
source share

More articles:


All Articles