Events call cuts off params?

Issue No. 137

Type

Bug

Status

Closed

Reported By

Raul Gil

Component

API

Resolution

Not a Bug

Votes

0

Created

27/May/13 8:45 PM EDT

Closed

28/May/2013 2:50 AM EDT

Description

I tried running this command on my box. curl --compressed -H "Authorization: Bearer I_INSERTED_MY_ACCESS_KEY" /events.json?date=20130526&sport=nba for some reason, the API is ignoring the second param and retrieving all the events that occurred on the date specified above. Also, is there anyway to pull data via GET requests with the ACCESS_KEY?

Closing Comment

Great, glad the problem was quoting the "&" in the shell. Curl is used in the API documentation only because it is simple and usually people can try it out right away without having to write any code. As we discussed a few months ago in email, there is a need to provide more complete examples in other languages. I have opened /api/issues/138 for this.

Comments

1. Erik Berg 28/May/2013 at 1:10 AM EDT

Are you running this command from Linux/Unix/OS X? If so, the "&" is a special character to the shell and must be quoted, otherwise the shell will spawn a child shell and run the command in the background. In this case, anything after the "&" is never sent as part of the request. You can stop the shell from interpreting the "&" as a special character by enclosing it in double or single quotes. For example: curl -H "Authorization: Bearer KEY" "URL" curl -H "Authorization: Bearer KEY" 'URL'

2. Raul Gil 28/May/2013 at 1:30 AM EDT

Thank Erik! Also, Do you think you could possibly allow passing in the ACCESS_KEY as a param in the request such as: /events.json?access_key=MY_ACCESS_KEY&date=THE_DATE&sport=nba I think that would be good for those of us who are not using curl to pull data from your API.

3. Erik Berg 28/May/2013 at 2:48 AM EDT

It is possible to include the API access token in the URI, but it is discouraged in lieu of including it in the HTTP header. Most likely will be disabled in the future. /METHOD.json?access_token=xxxx-xx-xxxx-xxxx&PARAM1=value&PARAM2=value The RFC (http://tools.ietf.org/html/rfc6750) comments: Because of the security weaknesses associated with the URI method, including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers MAY support this method. This method is included to document current use; its use is not recommended...