1

Our project came into discussion about URI pattern for Rest APIs. We have 90 days rate resources from each product, this API is to provide different days of rate resources for product.

The common pattern, from my understanding, is to set "days" as query params for "rate" resources:

{
  "uri": "/api/products/{:id}/rates?days={:days}"
}

But the URI provided by backend developers from our team is as following:

{
  "uri": "/api/products/{:id}/rates/{:days}-days"
}

I am not sure if the last one is anti-pattern, any thoughts?

Juan Du
  • 383
  • 2
  • 8

2 Answers2

0

AFAIK, it is not anit-pattern.

One common convention is that to use query parameters for optional parameters and path parameters for mandatory parameters. In your case if days are optional you may use query parameters. But its not anti-pattern if you use path parameters as you are using it.

This SO might help.

Community
  • 1
  • 1
sag
  • 5,333
  • 8
  • 54
  • 91
0

Both of those URI structures seem fine, I actually prefer the second, where it's not a query parameter.

However, REST does not dictate any URI structure at all. What it says is that you should not hardcode such URIs into client code. Resoruces should be discoverable/browseable. In this particular case, the products should have references to the "rate" resources .

Most of the time, if there is a limited amount of resources, they can be all referenced at once. I didn't understand how many "rate" resources there are for a product, but if it's a known amount, just link all of those under product.

If the amount of sub-resources is not known, or dynamic, provide a standard way to query (like forms in HTML). The server should be able to change the URI structure without actually breaking any clients.

Robert Bräutigam
  • 7,514
  • 1
  • 20
  • 38
  • Hi @Robert, thanks for your answer. The amount of resources is limited, I agree of the idea to distinguish these two if the resource is dynamic. – Juan Du Feb 06 '16 at 07:39