2014 Oct 01 5:48 PM
I'm glad to announce the unofficial session catalogue RESTful API to you! I created this based on an API that is in the development status (not for production). As a heads-up: Every app consuming that API should be highlighted as unofficial and not related to the TechEd && d-code activities. Also, the final end-points (URLs) might change during finalization, but I'll keep you updated!
I thought it's a great way for everyone to consume session data and build applications on top of that. I order to extend the provided API, I used apigee's API management cloud solution. Let me get into more detail
Apigee's API Management
Apigee enabled me to extend the exposed session data API. Apigee can be narrowed down to be an API proxy that allows me to trigger all sorts of actions within a lifecycle-oriented WYSIWYG editor in the browser! Obviously, it is way more than that - it allows me to run analytics, manage API users and apps, store data in the cloud and much more. You should try it out at www.apigee.com!
So, I created my free account and got started with it. Luckily, the apigee team provides an e-Learning class on how to build your first API proxy, which you can find here. I followed the class materials and created all the necessary flows, added caching and spike arrests as well as quotas to make sure that the used API in the back is not overloaded with requests in the future - during the TechEd && d-code event. By the way, caching helps a lot to minimize response times (the backend API is quite slow). Obviously, the first request will take longer. But as soon as the information is cached, your data will arrive very fast
In order to make existing the API more consume-friendly, I implemented the HATEOAS paradigm. This allows you to navigation through the data using provided URLs. For example: You could get the data for a certain session. This data will include speakers information. It has the ID as well as an URL that you can use to get the details of that certain speaker. One huge benefit is that your application will not need to load the whole data-chunk but rather get a subset of the data that is dumped out by the API in the backend. How did I implemented that you ask? Apigee allows users to execute custom JavaScript code to modify the HTTP responses. Using JavaScript, I was able to access the backend response and modify the response that got send back to the client. I was really happy about how easy the usage of the JavaScript SDK is. The documentation is very useful and there are many sample codes available to get started!
End-Points (Data Structure)
The exposed data can be separated into the following three entities: Sessions, Speakers, and Schedules. Let me start off by giving you the endpoints to get all entries per entity:
As already mentioned, all the detail information (e.g. speakers for a session) should be accessed via URLS (following the HATEOAS paradigm). So, as a next step, I added the functionality to look up certain entities by their IDs. You can get all the details of existing entities just like that:
From my point of view, there was one more thing missing: Search! So, I went ahead and implemented a search functionality which allows you to search certain attributes of the various entities. This way, you could for example look up all hands-on sessions, schedules that happen on a Tuesday, or all speakers that are SAP mentors. Basically, the search functionality enables you to provide a "query" that would need to be matched with the attribute values included in the search. Here's how to use the search for each entity:
Let me know what you think!
You may have recognized that this data endpoints are related to the TechEd && d-code in Las Vegas. The backend API provides session data for all the other events too (Berlin & Bangalore). I'll expose that data fairly soon too! But first, I wanted to get some feedback on the API. Is there anything you are missing? Would you be happy to use that API as it is? If so, I'll go ahead and expose all the events data and finalize my apigee API.
Looking forward to get your feedback!
2014 Oct 02 12:05 AM
I don't get data back for any of the API -
Is it still work in progress?
2014 Oct 02 12:08 AM
Yes, the backend API changed the structure of the JSON. Working on it right now!
2014 Oct 02 12:11 AM
Once the response json structure is finalized, would it still change later?
Its ok if the URL itself changes, but if the response structure is also unstable, that makes it difficult to write an app against it.
2014 Oct 02 12:16 AM
I can ensure that my response will stay the same. I'll talk to the backend provider to make sure that their response stays the same, too. I think it's just because they are still in development.
2014 Oct 02 12:18 AM
Cool! Would be great if you can announce once the response is finalized. Would love to play around with it
2014 Oct 18 9:10 PM
Hi Alexander,
keep on going!
There are some out there waiting for some APIs to play around with.
The official app is out in Appstore/Playstore, but don't trust an app you didn't made yourself!
(or do I mix it up with "charts"?
Any chance to get it fixed?
Christian