If you’re using CLI tool curl to retrieve data from a remote API, you might send forth a command like so.
curl -H "Authorization: Bearer access_token_goes_here" \ https://api.provider.com/thing/you_want/index.json
That results in a lovely JSON payload that makes you happy.
Let’s say that according to the API documentation, /thing/you_want/ accepts query parameters so that you can scope what you want to know about. Excellent! Instinctively, you try the following…
curl -H "Authorization: Bearer access_token_goes_here" \ https://api.provider.com/thing/you_want/index.json?scope=1
Rather than a scoped JSON payload that also makes you happy, you get back a message indicating that the API endpoint is displeased. Your sacrifice was deemed unworthy. Nay, YOU are unworthy. You are decidedly not happy.
What has gone wrong to anger the API gods so? You asked the wrong question of the API. More accurately, curl hasn’t formatted the request in quite the way you intuited it would.
To appease the API deities, the appropriate sacrifice comes in the form of a tweaked curl command. For example…
curl -G -H "Authorization: Bearer access_token_goes_here" \ https://api.provider.com/thing/you_want/index.json \ -d "query=scope=1"
We added a “-G” flag to make sure curl is sending a GET and not a POST. We also added a -d (for data) with the value of the API query parameter to be sent.
For More Information
linux man page on curl – read the section on “G/–get”
