Downtimes.2016/02/18
My hosting provider just told me that there will be downtimes this evening from 9pm until tomorrow 3am CET. These downtimes will be as short as possible but as it sounds there are two reboots of the host system. I hope all services startup again cleanly.
best,
daniel
things going on...2016/02/14
hi there, the last few weekends I started running the refactored twitter bot in production. In the beginning that was still way buggy, so I just let it run with eye-control. There were some little irregularities which I hope did not affect your software too much.
However, meanwhile it's running pretty stable and promising. I implemented some superior backend based on elasticsearch where you can like throw anything at and it tries to parse the data into my structures. I'm capturing like 70-80% I'd say of all fixtures, in case you wonder why there are some games updated slower than others. You can find more about the implementation and operation details soon in an extra article here.
Moreover the refactoring of the realtime data is almost finished, it became the Event-API. and you can find a short guide on it's functionality and how to set it up again - soon. So stay stuned :)
best,
daniel.
European Championships online.2015/12/14
hi there, for the impatient:
http://api.football-data.org/v1/soccerseasons/424
:-)
best,
daniel.
PHP library.2015/11/25
hi there, I've just put up a library that implements some functionalities of the API and showcases it's usage. It's neither complete, nor an eye catcher, but it's working :) You're welcome to extend the library and open a pull request. Setup a webserver, clone the repo from the underneath URI and call index.php to see it in action.
https://github.com/dfrt82/phplib-football-data
best,
daniel.
official release of v1 the 2015/12/03.2015/11/11
Okay I'm already a few month late, but due to nostalgic reasons I decided to 'officially' release v1 the 3rd of december due to the fact that that same day in 2014 the registration form and with it vital features of the API as it's running in alpha state right now were relased.
However, 'unofficially' v1 is already there and the impatient can play around with it, actually the links on the landing page are already pointing to the new version as the on-site-docs do. The base URI now reads (as you might have expected):
http://api.football-data.org/v1/
Most likely you won't spot too much changes at first glance. However, I'm still completing documentation and writing more samples that will showcase the new features. If you don't want to migrate (too soon) and you (currently think) you do not need new features you can stay calmed though: alpha version will keep running indefinitely.
best,
daniel.
small update: API outage on 15th of august.2015/08/16
hi there, due to a hardware breakdown of my provider all API services were down yesterday from around 9am to 3pm. Sorry for the inconvenience. Meanwhile v1 release is more or less done, some further testing but seems releasing to the end of august should be possible without problems. More on the features in a blog post accompanying the release.
best,
daniel.
small update.2015/07/05
hi there, as new seasons' schedules slowly but surely getting public I integrated those available, others will follow. Development of v1 still in progress and I hope I can stick to my self-imposed schedule. I'll keep you posted!
best,
daniel.
almost the end of season: further roadmap.2015/04/23
lots of you guys not just ask about a desired feature but keep asking about a (strategic) roadmap of the API, so let me touch that topic and give you some information what you can expect in the future.
In August 2015 version 1 of the API or short "v1" will be released. After almost 2 years of running beta and alpha versions successfully, I'm glad to offer the first version that is also stable in it's name. As far as I can tell by now it won't get too much new features (thus, most likely will be fully backwards compatible to alpha), but will merge the best features of beta and alpha version, e.g. you will be able to switch from concise to expressive output. But more on the (final) features will be announced in the documentation.
Mostly invisible to endusers but very important for me is that with v1 I will finally switch to a new platform and the API will finally be upgraded to Java 7. That will involve major refactorments as well, as Java 7 acts differently in terms of date or regex operations.
As mentioned earlier the API emerged out of a privat project which is why the majority of the team names is german. This will change as after the last game for season 2014 was played all team names will get standardized to english.
I intent to move the homepage to Hugo (slowly but surely I need pagination for that blog...) and upgrade the documentation to Asciidoctor, just to mention some cosmetic changes as well :)
Another question that's raised very often is if the API really is and will continue being free. Actually the answer is yes but it depends, because it's only free for non-commercial use. If you use the data commercially, please get in contact with me, so we find a fair-minded solution that pleases both of us. Besides I can give you important background information on how the API 'ticks' internally so you can optimize your integration and last but not least I'll offer you some additional advanced endpoint functions to make the API fit seamlessly with your existing data.
Last but not least I want to add a FAQ site, extend the code samples and also add some client libraries but I gotta see how much time is left. In the end, this blog post answers another often asked question in itself: Will this API remain online and will I keep supporting it and the definite answer is: absolutely!
daniel.
small update: direct date usage.2015/03/24
I extended the usage of timeframe based requests as you now can specify the dates directly. Just set the two parameters timeFrameStart and timeFrameEnd to a date in the format yyyy-MM-dd. So e.g. a request to show all games of the first 5 days of march looks like that:
http://api.football-data.org/alpha/fixtures/?timeFrameStart=2015-03-01&timeFrameEnd=2015-03-05
All resources that support the timeFrame-Filter now also support these two filters (that always must be used together).
daniel.
new feature: realtime scores.2015/02/16
Frequently I was asked if I also plan to offer livescores. At first I did not want that, I never intended the API to offer that kind of data. I think a RESTful architecture is not really suitable for distributing (near) real-time information. However that question remained and I couldn't forget about it. So I did some research if it's somehow possible and when I found out it actually is, I decided to try it out and there we go.
At first I asked myself what livescores really are. How live do they have to be? I found out that livescores advertised mostly aren't that live. Websites pretending to offer livescores show a goal 2 minutes later than I could see it on television. That's not my definition of live. And because I want to express that by live I understand the freshest data possible I want to distance myself from that widespread livescores. And that's why I wont' offer live, but realtime scores.
And what's so wrong about REST and realtime data?
Actually it's the protocol, that is HTTP. Let me back that up. Remember the Champions League final 2012? Chelsea was playing some kind of Catenaccio and Munich was simply not able to crack the defence until the 83th minute, when Müller scored a header. Drogba striked back and then there was extra time and frequent action in terms of goals. However, what would have happened technically? Well actually the first 83 minutes our RESTful application had to ask every minute for updated data. So at least one request every minute, makes up to 83 requests. Some guys maybe coded some nice Comet or Web Sockets and want to be even "more live" and decide to poll 3 times the minute. That makes around 250 requests - for nothing but the information that nothing happened. So it seems we're wasting resources and that's caused by architecture.
So what to do? One solution is the use of callbacks. A client tells the server a callback endpoint and the server acknowledges it's reception. So to stick to our example nothing happens until the 83th minute where the server requests the callback and thus notifies the client about something happened. We saved 250 requests, so that should do it. In fact I considered that solution but it has the drawback in that the client has to switch roles and implement server functionality and the same but vice versa applies for the server. Twitter provides another solution with their Streaming API. They use regular HTTP but unlike closing the connection after sending data, they keep it alive and resend data upon arrival. That works as well but actually I don't see any reason why one should stick to HTTP. I think HTTP simply wasn't designed for such use cases and thus shouldn't be misused for.
So to cut a long story short I decided to implement a solution based on AMQP, a binary protocol. Or to be precise I implemented a solution that combines REST and AMQP and I wonder that I couldn't find one API that does that as well and already. Well if there is something fundamentally wrong, I'll find out. Have a look at the setup guide for realtime data to see how to implement that in your application.
daniel.
new attribute: status on fixture resource.2015/02/03
I added some basic code examples for beginners to the documentation section. Basically I wanted to answer FAQs that often come in via mail and test a syntax highlighter for some more advanced code examples to follow, as I'm proud to announce that I'll finally add live near-realtime scores.
I'm planning to release a first prototype with the round of the last 16 of the Champions League, which takes place the 17th of February. As I'm gonna watch the games anyways it won't be much of a problem to input the data by hand and test how and if my imagined design will work out. Stay tuned to get instructions the next days on how to participate in testing.
Mentioning design I also came up with this state diagram for the status field of the fixture resource.
Guess it's pretty self-explanatory except the difference between SCHEDULED and TIMED, which is because fixtures typically first get scheduled (that is: get a rough date (range) it will be played) but get timed (that is: get an exact date and time it will be played) much later. For instance fixtures of the Bundesliga are typically scheduled once a year and about 6 weeks before the scheduled date, when officials know when and who will play european games, they get timed.
daniel.
why one should use football-data.org2015/01/28
Though I state in the about section that I cannot guarantee the data to be accurate, accuracy is the answer. Recently the 20th matchday of the Premiere League catched my attention. Chelsea and ManCity were precisely equal in all terms, though BBC, The Guardian, Sky Sports and even the official Premiere League page itself state Chelsea is ranked on top while ManCity only owns 2nd place.
Though I don't think this was on purpose but on the fact that a default order sorts C before M, this issue remains unfair and if I trust this wikipedia link it's simply wrong: Teams are ranked by total points, then goal difference, and then goals scored. If still equal, teams are deemed to occupy the same position.
Maybe these guys should rely on data of football-data.org ;-) See my League Table of the 20th matchday, which does not disadvantage anyone but places teams according to the rules.
daniel.
alpha online.2015/01/18
So that's it, alpha is online. Few days ago I linked the resources on the landing page to the new versioned release alpha. I don't wanna explain or talk too much here about the features as you can read everything in the documentation.
Unfortunately not so nice requests where I couldn't figure out any sense behind increased rapidly, so I had to implement throttling. I did not design it that much and most likely it will change, but for the first shot everyone is limited to 15 requests per minute which is like 900 requests per hour.
Update: See the documentation for the rate limit convenctions.
If that hinders your current implementation immensively, contact me as it's possible to set more gentle limits for certain authentication token.
Next steps are to put some code samples to the documentation and maybe publish a roadmap. But before that I'll take a short break and review everything there is so far.
so long,
daniel.
alpha on track.2015/01/06
hi there and a happy new year!
Just want to drop a line that alpha version is on track and will be released the 18th of January. The implementation is almost complete, just some tests and documentation need to be finalized.
In short a few appetizers:
  • introduced versioning.
  • you get access to football data down to 2005, useful for statistical analyzes.
  • the resources are better linked and more talkative, holding more information.
  • I added the Champions League (to beta version as well and already).
  • I improved the process of updating results.
Notice that I did a data cleanup as well and the league shortcuts changed from lower to uppercase.
I don't think alpha is perfect at all (which is why it's alpha and not v1), but I think it's already much better than beta. It ran for almost a year now and likely will further run for another, but won't get any updates or changes any more. I think it's no problem to change evolve an API as long as the changes are backwards compatible and don't break clients. So I'm gonna work only on alpha from now on.
daniel.
major upgrades.2014/12/03
I finally managed to add some kind of design to the page. It's not my strength, but I guess it's way better than before. So enjoy it :)
Besides I added the possibility to access the API using an authentication token. Click on Free API Key in the menu for more information.
The resources itself did not change, nor did the filters. Well at least not yet. Thanks a lot for all your feedback, I'm trying to merge all your suggestions in perfect endpoints, but as requirements differ immensely I cannot satisfy everyone's needs completely. Anyway I have some neat ideas in mind that will be transformed into code until next year.
I guess the API is then finally ready to lose beta status and get stamped stable :)
daniel.
small updates.2014/11/17
I added better error handling to the API, so now you get meaningful hints on why requests failed or did not respond like you expected.
Moreover I changed the structure of the ranking subresource which now holds the matchday but not the needless array around the position-objects any more. As the JSON-viewer for FF did not show me that error in the response, I switched to the REST Easy plugin which is a good alternative.

Still thinking about versioning and introducing a (free) API-key for usage. Planning on releasing these upgrades to the beginning of the new year.
I'll keep you posted!
daniel.

introducing the timeFrame argument. 2014/10/13
I wasn't happy with the 'upcoming' and 'past' URIs, as neither upcoming nor past were (sub)ressources, but their appearance in the URI made them appear like that. Also some good feedback of you guys concerning the way to retrieve upcoming games made me re-think this whole thingy and I came up with the subsequent solution.
The URIs vanished completely and their intent turned into the timeFrame argument. Actually you cannot request a number of past/upcoming games any more, but you can define a timeFrame to display fixtures in.


For instance, if you'd like to get all completed games of the last two weeks for a certain team you'd do a GET to /team/22/fixtures/?timeFrame=p14. To retrieve all games of all available leagues in the next 4 days, you'd GET to /fixtures/?timeFrame=n4.
I hope you grasp the idea. I think this is a pretty handy solution and I guess you're now way more flexible in building applications to your needs.

btw: The 'old' URIs still work due to compatiblity but are not documented any more. (which reminds me to introduce some kind of versioning)

cheers
daniel.
small pragmatism change: pluralization 2014/10/09
I decided to change all URIs to plural. So /soccerseason is now /soccerseasons and so on. This from now on applies for all (sub)ressources, though - as always - the old URIs will still work for compatibility issues but are not documented any more.

cheers
daniel.
new ressource: fixture. 2014/09/10
I decided to introduce 'fixture' also as a main ressource to be able to pull upcoming fixtures across all leagues easily. You can filter by days, so if you wanna see all upcoming features for all leagues, you'd GET to /fixture/upcoming?days=2.
I really had to think about that and hope it does not puzzle you as 'fixture' is now a subressource for team and socceseason but also a main ressource.

cheers
daniel.
let the games begin. 2014/08/25
The major leagues are imported and get their updates every night. Any league missing? Drop me a note and I'll see if I can add it quickly.
Besides it's now possible to filter the fixture ressource. I implemented a venue filter and the long planned count filter; so you can now specify the number of games returned so you can only return those games that e.g. took place in the home stadium.
Keep me posted for desired features, API stability and you know - feedback.

cheers
daniel.
content update for new seasons' data. 2014/07/16

Hi all u football associates out there :)
Actually I'm doing an initial import of all the new seasons' data at the moment. You can expect all data to be complete to the end of july. As you can see, moreover I decided to add a small blog section to keep you posted about important changes, explain features, best practices, hints and so on.

cheers
daniel.