A Prototype API for Joind.In
Following the principle of “release early, release often”, I put live a very early version of the v2 API for joind.in today (so that I can use it in another project!). I haven’t updated the documentation yet but in case anyone was thinking of consuming data from joind.in, this at least gives you an idea of the direction of the project so I thought I’d share.
Things you need to know:
- The service is an HTTP Web Service. Meaning it’s RESTful apart from when it isn’t
- The endpoint is here: http://api.joind.in
- You can fetch data about events and talks (read-only) at this point
- Formats available are HTML or JSON. The service will guess from your accept header but you can override it with
?format=jsonor?format=html - If you need more columns than you get by default, you can add
?verbose=yesto your request - Pagination is available, with parameters
resultsperpage(default 20, set to zero for no limits) andstart(default zero) - The service supports OAuth1.0a, which isn’t useful at this point as we’re read-only but it will come into play as we add functionality
Examples
Events list: http://api.joind.in/v2/events
Information about DPC11: http://api.joind.in/v2/events/603
Talks at DPC11: http://api.joind.in/v2/events/603/talks
Your Thoughts
Comments are welcome on this post. Bugs and feature requests should go to http://joindin.jira.com, read more about Joind.in and its community at http://joind.in/about
Thanks for releasing early! I’m all into API’s & REST with the ultimate goal of using as much as possible for DPC12 :)
I’ll probably be in touch soon as I expect to get stuck pretty soon as I’m rusty at this…
Love Joind.In!
Tom
Tom, thanks for the comment and also the enthusiasm. Hopefully the new API will be intuitive to use, look forward to seeing what you build with it!
Lorna,
the API looks quite fine to me. Here are just some minimalistic remarks:
– I couldn’t find a real reason for the “verbose” flag. Is there any resource, that has that many fields so that it makes sense to hide some by default?
– Although “resultsperpage” is semanically more substantial, I’d personally go for “limit” instead. At least for me, it’s more intuitive and I bet lots of web devs have the same issue. Thanks MySQL! ;)
– It might make sense to use XML instead of JSON, for better extensibility and validation purposes.
I wondered why I cannot see any comments here: http://api.joind.in/v2/talks/3240/comments It’s the comment list of my “Advanced OO patterns” talk at DPC, which shows quite some comments on the website.
Cheers,
Toby
Toby: Great to get some input, thanks for dropping by! The events objects are a great example of where there are fewer fields in the response by default, but if you want detailed stuff such as CfP info or location data, you will use the verbose flag.
As I said in the post, comments are not implemented yet (but I just looked over Akrabat’s shoulder sat next to me and maybe we won’t have to wait long…)