We've listed some common knowledge about using HTTP and HTTPS. There are of course many articles regarding this topic available on the web, but we'll try to cover those that we see as common questions and issues from our users here. These hope to deal with common questions and mistakes we see when users are working with our API.
URL Encoding - Percent Encoding
When working with HTTP requests, it is important to think about URL encoding, especially when working with strings that are being packaged to form the HTTP request. I'd recommend reading up on Wikipedia about URL Encoding (also known as Percent Encoding).
An example, for a HTTP GET request to read data from a data source that has an alias of "test data". In this case, the alias has a space in it, a non-alphanumeric character. The One Platform does support any byte characters in the alias field.The GET request would look something like this, notice "test data" is encoded to "test%20data".
GET /api:v1/stack/alias?test%20data HTTP/1.1 Host: m2.exosite.com Accept: application/x-www-form-urlencoded; charset=utf-8 X-Exosite-CIK: 27951d1a260b4b258fe......
Proper Request Response
HTTP/1.1 200 OK Content-Length: 17 Date: Thu, 04 Apr 2013 14:11:28 GMT Server: misultin/0.8.1-exosite Connection: Close test%20data=hello
If I did not do this, I would get an error response because the server is getting a bad URL request.
GET /api:v1/stack/alias?test data HTTP/1.1 Host: m2.exosite.com Accept: application/x-www-form-urlencoded; charset=utf-8 X-Exosite-CIK: 27951d1a260b4b258fe......
Improper Request Response
HTTP/1.1 400 Bad Request Content-Length: 24 Date: Thu, 04 Apr 2013 14:29:15 GMT Server: misultin/0.8.1-exosite Connection: Close HTTP/1.1 400 Bad Request
Required Newline characters CRLF ( \r\n )
HTTP requests require newline characters after each line, for requests that include a body (POST) you must have a empty line between the headers and the body, and for GET requests to end with an empty line after the headers. This is so the server knows the headers are done and if it should wait for anything else before acting upon the request.
For systems and code bases that provide HTTP libraries or modules, this may not be important as the module does the work for you. For embedded systems that require you to create the HTTP packet as characters to send over a serial port for example, you will need to make sure to include the newline characters CRLF ("\r\n").
If you are getting "HTTP/1.1 400 Bad Request" messages, check each line you are sending ends in CRLF and that you have included the empty line after your headers.
An example, for a HTTP POST request to write data to a data source that has an alias of "data". The POST request would look something like these two examples which are identical, the first is just broken up line by line, notice the blank line between Content-Length header and the body (data=1).
Proper Request (line by line)
POST /api:v1/stack/alias HTTP/1.1\r\n Host: m2.exosite.com\r\n X-Exosite-CIK: 27951d1a260b4b258fe......\r\n Content-Type: application/x-www-form-urlencoded; charset=utf-8\r\n Content-Length: 17\r\n \r\n data=1
Proper Request (continuous characters)
POST /api:v1/stack/alias HTTP/1.1\r\nHost: m2.exosite.com\r\nX-Exosite-CIK: 27951d1a260b4b258fe......\r\nContent-Type: application/x-www-form-urlencoded; charset=utf-8\r\Content-Length: 17\r\n\r\ndata=1