API Chatter

[Gandalf]

don't send the API key as a parameter in the URL. There is nothing to stop an attacker accessing this and impersonating someone else (potentially with more access rights). Additionally, if you are building a REST API, it doesn't describe the resource being requested, and makes responses difficult to cache;

Thanks... sounds sensible... will log on trello for future development. I think this is fine for now; the infrastructure will still work if I change the input method.

send it in the body of the request, and require a https connection.

https costs money. It's a probable purchase for the future. I'm also mindful of the lack-of sensitivity of the data that I'm holding... it's not a priority at this stage of development.

Also, it didn't work for me - I got some message that I can't remember. I didn't try very hard though, will try again later.

There are a variety of error messages built in, hopefully they should explain your problem, if not pass it on here & I'll try to help.

[id3nt1ty]

https costs money.

Let's Encrypt doesn't.

I'm also mindful of the lack-of sensitivity of the data that I'm holding... it's not a priority at this stage of development.

It's not the data I'm suggesting you secure, it's the API key. Otherwise, why have it at all?

[id3nt1ty]

There are a variety of error messages built in, hopefully they should explain your problem, if not pass it on here & I'll try to help.

{"error_code":300,"error_description":"Parameter in unexpected format"}

Do I need to enclose my key with something?

[Gandalf]

Let's Encrypt doesn't.

Interesting...

It's not the data I'm suggesting you secure, it's the API key. Otherwise, why have it at all?

Maybe I wasn't clear, what I mean is, the repercussions of having an API key compromised in the short term is pretty small, because there is no sensitive data that can be gained from it. Long term I agree with you. I've added a trello card called "improve api security" where I will look at all of these things. For now the scope of my work is getting the JSON format to your liking.

Do I need to enclose my key with something?

No you shouldn't.

Either your version number isn't an integer, your match_id isn't an integer or your api_key is not a 32-character base62 string. To be honest I was having troubles with verifying that last one so it's quite possibly an issue with the code, I will have a look at it tonight or tomorrow.

[Gandalf]

Either your version number isn't an integer, your match_id isn't an integer or your api_key is not a 32-character base62 string. To be honest I was having troubles with verifying that last one so it's quite possibly an issue with the code, I will have a look at it tonight or tomorrow.

Amusingly, the verification code I refer to is entirely correct, what actually happened was that I managed to create 31-character API keys for us. I've added a character to them in the database. Stick a capital R onto the end of the key I sent you, and it should work for you.

[id3nt1ty]

Haha ok - I did think about checking the length but thought surely not

[Gandalf]

Tentatively done.... change the version number in the API call to 2 and let me know what you think!

I think it's in the format you wanted. The only extra thing it does compared to the old BBDB is give a list of the touchdown scorers (not the turns yet). It gets increasingly more complex to add in more things, eg longest passer. It's doable but I want to move on to other things first, and I figure that what's provided in v2 is enough for you to produce an output.

[Gandalf]

I'll do a team API and a league table API at some point. I think that will cover the 3 sorts of images that BBDB did?

Not going to do those until someone's going to use them though. id3 has said that this is on his back-burner at the moment. But I just wanted to outline the future plans.

[id3nt1ty]

Cheers, should be looking at game images next week.

What really would be useful is an API to get the list of matches (this page: http://gandalfgames.net/bbdb/matchlist.php).

That would allow a user of the image generation stuff to:
see the matches and click a button to generate their image;
rather than:
find the match in BBDB, remember the match ID, type it in to the image generator, then click a button to generate their image.

But I'd understand if you wanted to wait until people actually have somewhere to have to do the remembering and typing in.

[Raveen]

BBM Offered:
Match Summary (multiple variations mostly cosmetic logo)
Team roster
League Table
League Stats - Team (2 variations)
League Stats- Players (2 variations)
League Graveyard
Team Signature (2 variations)

Personally I'd prioritise League Table, Match Summary and Team Roster. Sigs would be great too though.

[Gandalf]

League Graveyard

Oh! I should definitely do that page on BBDB. Easy peasy to do, plus I can improve on what BBM did and show which team (but not, alas, which player) they were killed by. I'll add a task to Trello.

What really would be useful is an API to get the list of matches (this page: http://gandalfgames.net/bbdb/matchlist.php)....
But I'd understand if you wanted to wait until people actually have somewhere to have to do the remembering and typing in.

Indeed, I'm not doing any more work on API's until you do some As an alternative I could have a link on BBDB direct to your image creation thingy.

[id3nt1ty]

I've been messing around with this tonight, and here are some suggestions for when you look at this again.

It would be great if every response to an API request returned JSON of some sort. Successful requests are obvious, but it would be great to be able to have error reports in JSON too. For example:

Code: Select all

{
  "error": "Match report not found."
}


It would also be great if the HTTP response code represented the result of the request too. So 200 for a successful request, 404 for match report not found, 401 for unauthorized request (bad api key for example). It makes it much easier to handle the result of the request as one always has access to the http response code, without having to parse the body to figure out if the request was successful or not.

I found the following post very useful when designing my own REST APIs: http://mark-kirby.co.uk/2013/creating-a-true-rest-api/

[Gandalf]

It would be great if every response to an API request returned JSON of some sort. Successful requests are obvious, but it would be great to be able to have error reports in JSON too. For example:

Code: Select all

{
  "error": "Match report not found."
}


I have 6 error message set up like this already. Try, for example, not giving an API key, giving an invalid API key or not stating a match_id. Why did you have to find the one error message that isn't returned in JSON format?!

It would also be great if the HTTP response code represented the result of the request too. So 200 for a successful request, 404 for match report not found, 401 for unauthorized request (bad api key for example). It makes it much easier to handle the result of the request as one always has access to the http response code, without having to parse the body to figure out if the request was successful or not.

I found the following post very useful when designing my own REST APIs: http://mark-kirby.co.uk/2013/creating-a-true-rest-api/

Will file away for future reading, ta.

[id3nt1ty]

Why did you have to find the one error message that isn't returned in JSON format?!

Ha, sorry Gandalf. I just tried a match ID I knew wouldn't exist...

[Gandalf]

You will now get a nice error code for an invalid match ID.

I've also re-jigged some of the error codes, so they fit into an error code scheme that is detailed on the skeleton API guide page here.