I use the 511.org API and one question I see come up frequently on the support forum are requests to increase the number of API requests possible using an API key. The answer is pretty straightforward, the 511 API is not intended to serve as your application’s backend. If you want to serve the data to large numbers of users you’ll need to use your API key, fetch the data, cache it on your own backend and serve it from there. You can then use your API key to refresh your own cached data and serve your application.
Another question that often comes up is access to historic data which, as of this writing, the API simply doesn’t provide. I would doubt the 511.org team will offer historic data anytime soon (if ever). If you’re looking for historic data the answer would be to build your own backend and archive the data.
To request an increased rate limit, you can provide the following information to firstname.lastname@example.org:
- your API key
- the rate limit you need
- a description of the use case
- data endpoints you intend to use
- a brief justification for the requested rate limit
I’ve worked with a lot of DOT type data and I have to say Massachusetts takes the cake for a seemingly unnecessarily complicated authentication process. The processes is documented on their /auth-token API.
This endpoint is available to all authorized users. The content of the response is the same for all user groups. The Bearer signature generation that uses this token is performed as follows.
Ok, here is the six, yes six step process to authenticate MASSDOT APIs:
Step 1: Concatenate the user’s secret key with the token provided herein, separated by a colon. (‘SecretKey:token’)
Step 2: Create a SHA256 hash of the concatenated string. (i.e. SHA256(secretKey:token))
Step 3: Convert the generated hash to a hexadecimal string representation
Step 4: Concatenate the user’s username with the hexadecimal hash, separated by a colon. (‘username:hexadecimalHash’)
Step 5: Create the base-64 string representation of the concatenation. (Base64(‘username:hexadecimalHash’))
Step 6: The result is the signature required for Bearer type authorization. (Authorization Bearer ‘generated signature’)
Btw, I provided this gist to MASSDOT in the event they want to link/share for other developers.
Here’s a simple example of calling the vSphere REST API using curl. These commands first authenticate to the API which creates a vmware-api-session-id cookie which is stored to cookie-jar.txt then makes a request to get a list of VMs:
curl -k -i -u email@example.com:password -X POST -c cookie-jar.txt https://vcenter/rest/com/vmware/cis/session<br>
curl -k -i -b cookie-jar.txt https://vcenter/rest/vcenter/vm<br>
NOTE: Use with caution as your credentials will likely be caught in your command line history!
Here’s a related post on vSphere SDKs.
Check out the new VMware developer.vmware.com portal!