Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite
1

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.

share|improve this question
"Should the number be appended to the URL" What number? – Chuck Stephanski Mar 28 '11 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 '11 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. – Chuck Stephanski Mar 28 '11 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 '11 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. – Martin Blore Mar 28 '11 at 18:47

1 Answer

up vote 9 down vote accepted

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:

/clientName/appName/methodName?maxrows=10

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:

/clientName/appName/products?like=foo
/clientName/appName/items?maxrows=10
/clientName/appName/items/keyboards/msnatural
share|improve this answer
1  
Everything you say is right on point – qes Mar 28 '11 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 '11 at 20:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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