If you happen to have Go installed I've made an example
packagemainimport("fmt""net/http")funcAmazingAPI(responsehttp.ResponseWriter,request*http.Request){foos:=request.URL.Query()["foo"]fmt.Fprintf(response,"you foo'd me good %+v",foos)}funcmain(){handler:=http.HandlerFunc(AmazingAPI)http.ListenAndServe(":8080",handler)}
Worth noting there's nothing in the URI spec for query to require this behaviour (it doesn't even require key=value, just that query strings are 'usually of the form key=value').
But it's definitely more conventionally used the way that @quii
is describing - see for instance this on SO.
Yes it is a shame, but it is for sure the convention
Best thing to do is write a test for your server and see if the library behind it supports it. If your server supports it, you're all good and you'll hopefully make it easier for your clients
Sorry it is plural, my call isnt even addressbook I was just trying to simplify for example sake. I did over look the asc and desc thank you!
And yes comma separated was the idea I had to go with, just felt like it might not be the best! But ill take a look at that topic now.
Please dont do comma separated
The HTTP spec lets you do
order_by=field1&order_by=field2
. Most decent HTTP servers and clients will support this out of the box.So your clients dont have to write special code to send multiple values and you dont need to do any parsing code yourself.
Wow, I didn't know you could do that! Will that respect the order the parameters were set, though?
Yup (or at least it should!)
If you happen to have Go installed I've made an example
Hitting
http://localhost:8080/?foo=1&foo=2&foo=3
Results in
you foo'd me good [1 2 3]
Worth noting there's nothing in the URI spec for query to require this behaviour (it doesn't even require key=value, just that query strings are 'usually of the form key=value').
But it's definitely more conventionally used the way that @quii is describing - see for instance this on SO.
@quii you're right! Better than using commas
Yes it is a shame, but it is for sure the convention
Best thing to do is write a test for your server and see if the library behind it supports it. If your server supports it, you're all good and you'll hopefully make it easier for your clients
As much as I like this, I don't think Core/Linq supports this
Let me add more detail to that,
I am getting a list of Resource Parameters
FilterBy
OrderBy
etc
This is only taking in the first OrderBy parameter I send in the URL.