What is the best way to design a HTTP request when somewhat complex parameters are needed?

Question

I have some web services that I am writing and I am trying to be as RESTful as possible. I am hosting these web services using a HTTPHandler running inside of IIS/ASP.NET/S

Answer 1

I recommend you to read the HTTP 1.1 specification, especially the sections 3.2 Uniform Resource Identifiers and 9.1.1 Safe Methods. Those will hopefully answer your question.

---

Here’s some additional information:

• The Definitive Guide to GET vs POST
• URIs, Addressability, and the use of HTTP GET and POST

Answer 2

If you are generating these long urls on server, you can make use of compression for path info.

So if you have something like /?param1=bla-bla&param2=bla-bla you just compress that parameters and make url looks like /?query=ASsadcnfAFFASFscnsdlc

When you get such request, you just decompress them and parse parameter string

Answer 3

You should place the parameters in the query string, using an HTTP GET request. Limits in some older web browsers are not a concern, because the only people browsing through an API in a web browser are likely to be developers (or at least technical).

Remember that client applications should not be manipulating the URLs your API provides them. URLs are opaque identifiers to the clients, used only for directing them to where particular resources may be found.

If this is not possible for whatever reason, I would use a POST request with the parameters form-encoded into the body. It won't be entirely RESTful, but assuming your resources are designed properly the impact on client code should be minimal.

Answer 4

I'd aim for HTTP POST. It's nicely tokenized when it gets to PHP (or whichever you're using) and it doesn't have the size limits the others have.

Answer 5

Use custom HTTP headers with HTTP GET if nothing else works out. HTTP headers can be set by nearly all clients.

Generally it is best to use URL parameters in the query string. Too many URL parameters indicates that you need to split into more fine-granular services.