I am currently designing a API and have come to a slight design issue and was hoping for a few other opinions. My url structure for accessing basic data from the API is: /clientName/appName/methodName/. Basically each client may have a different set of methods for each application, so the base application class is extended through each client if the file exists. My question is with limiting the data pulled back through a GET request. Should the limiting number be appended to the URL or is that something that should be handled through POST request only? Should it even be a option? Looking for best practices in this scenario, thanks.

  • "Should the number be appended to the URL" What number? Mar 28, 2011 at 15:56
  • The limiting number, so /clientName/appName/methodName/10 would pull back the top 10 records. Sorry for the confusion, hope this clarified things.
    – chrisw
    Mar 28, 2011 at 16:01
  • 1
    Sure it's totally legit to put that on the URL. In Spring /clientName/appName/methodName/ would resolve your controller handler and 10 would be passed in as a parameter. Mar 28, 2011 at 16:22
  • So then it would be wise to pre-limit the list brought back to let's say 50 and then use the parameter based limit to filter that result set? I'm just trying to prevent users from hitting the data repeatedly with large result sets.
    – chrisw
    Mar 28, 2011 at 17:06
  • Your URI structure shouldn't be concerned with preventing users form hitting data repeatedly. This is a policy you should place on clients of the service, in your service logic. Mar 28, 2011 at 18:47

1 Answer 1


The URI ending in "10" representing maximum returned rows is not a resource. Your number "10" is scope. Scope belongs on the query like so:


Furthermore, you wouldn't pull back data on a POST request. You're POST'ing data to the web server, you're not asking to GET.

I'd also question having "methodName" in the URI, this smells of RPC over a GET request. This is not how URI's should be designed. I see that as someone being tempted to do a HTTP GET '/clientName/appName/saveData'.

Think of your application as resources:

  • 1
    Everything you say is right on point Mar 28, 2011 at 19:05
  • Well the reason for the method names is the schema is far more complex then something simple as a product or item. The method is a wrapper if you will for logic that is required to bring back the data (lots of joins). The database schema the company is using isn't normalized at all, so hence the wrapper methodology. I understand the difference between POST and GET, my point was where to add the logic either through the GET request or the POST request. I do agree with utilizing the variable naming methodology, makes more sense and provides more flexibility. +1 for a helpful response.
    – chrisw
    Mar 28, 2011 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.