This is a blog from 2017, original of this post can be found here. I thought to propose a reedited version here, with some updates and additions. The activities mentioned in this post are the first steps that brought to the foundation of Hydra Ecosystem, our brand-new Open Source Organisation.
With the same enthusiasm this year as well, my adventure as Mentor for Google's summer programme (Summer of Code or GSOC) has happily started and been completed. A great opportunity is offered to students world-wide to understand the Open Source ecosystem and experience real-job activities on the field of real-world OS organizations, by contributing to software repositories while been funded by Google Open Source. This year I managed to organize a super-powered team, putting together efforts from:
- Python Software Foundation's mentorship programme, very active in facilitating access for smaller OS organizations;
- W3C Hydra developing group that is designing a very interesting specification to make Web APIs (in particular REST) to communicate automatically (see Hypermedia for a general introduction);
- Two kind students that had the great feeling for understanding the importance of what we are doing, and decided to submit proposals to realize the project: Chris Andrew and Akshay Dahiya.
Hydra
Hydra is a tool defined in a draft registered at W3C and the specification is in active development by Markus Lanthaler and the members of the team (video presentation here) in the working group.
Hydra is a client-server framework (based on W3C's RDF) used to describe and publish Web APIs to network agents. Through modeling a high-level data-structure ("ApiDocumentation" or shorter "ApiDoc", written in JSON-LD), leveraging the semantic tools provided by the specification, developers can make their data accessible to any Hydra-aware client around.
Accomplishments
The Hydra client-server system that makes possible the implementation of this framework can now be set up easily by adding your own custom ApiDoc to a server software codenamed hydrus (Hydra Universal Server), that has been developed by the students this summer. Hydrus let developers to run the system through a two-steps procedure: writing once their ApiDoc and start-up the server with or without pre-loaded data (complete instructions here).
ApiDoc can be written once at system design phase and amended later if needed; clients asks for the ApiDoc when handshaking with the server and this way they are automatically able to operate the interface, implementing the business logic that drives them. Once the system is set up server-side with the right documentation and data, any Hydra-aware client can connect and start operating with the interface (clients can be found here and here, here an example of ApiDocumentation).
The next idea that has been implemented during this summer is a visualization of all the work done by Hydra in the background of a complex network. That is why we came up with developing a graphic interface that simulates a real-world scenario and displays every API interactions going on. We called this browser application hydra-flock-demo. The flight of a flock of commercial drones is simulated to demonstrate how Hydra documentation can make the built-in clients in every drone to communicate changes of state to a central server; every component in the simulation is both a Hydra-aware client and a hydrus server instance.
Unexpected outcome
The ones described above are quite cool achievements to demonstrate how a Python-Hydra implementation can easily bring automation in a network of Web interfaces. As spill-overs we have been experiencing great insights into designing and implementing with Python functional programming tools a quite usable small-scale DBMS for storing semantic triples using PostgreSQL, see the design here and data model here. Furthermore, some nice options came up about how to index this data using an HexaStore for example, all the experience has been really fruitful since we started with the preparation in February. More insights have arose from understanding smart devices' operational procedures and how to make them send/receive signals and perform message-passing operations efficiently, the protocol for drones' communications is super-simple and clear, meant to be efficient in terms of frequency of messages and size of payloads.
All this material is going to be object of live-demo events to bring these tools to reach a wider audience. You can read students blog posts describing in more detail this adventure here and here.
Potential growth
In the scenario of interconnected devices (IoT) and linked knowledge-bases, Hydra and its ecosystem of tools can lead to higher level of integration and automation between agents. The possibility of driving a network of APIs by adjusting and improving their documentation is incredibly interesting for data but also for cloud services.
Thanks again to Python Software Foundation, W3C-Hydra and Google.
Where to start
We are developing an ApiDoc from scratch in this repository. That is the easiest way of having a grasp about what Hydra is about.
Update
After two year of dedication these activities brought to the foundation of Hydra Ecosystem.
References
- M. Lanthaler, "Full-on Hypermedia APIs with Hydra," presented at the API Strategy & Practice Conference.
- C. Pautasso, E. Wilde, and R. Alarcon (editors), "REST: Advanced Research Topics and Practical Applications," Springer New York, 2014.
- L. Richardson, M. Amundsen, and S. Ruby, "RESTful Web APIs," O'Reilly Media, 2013.
- M. Lanthaler, "Building Next-Generation Web APIs with JSON-LD and Hydra," presented at the Symfony Live Portland 2013 [slides] [video].
- M. Lanthaler and C. Gütl, "Hydra: A Vocabulary for Hypermedia-Driven Web APIs," in Proceedings of the 6th Workshop on Linked Data on the Web (LDOW2013) at the 22nd International World Wide Web Conference (WWW2013), 2013 [slides].
- M. Lanthaler, "Creating 3rd Generation Web APIs with Hydra," in Proceedings of the 22nd International World Wide Web Conference (WWW2013), 2013, pp. 35–37 [slides].
- M. Lanthaler and C. Gütl, "Model Your Application Domain, Not Your JSON Structures," in Proceedings of the 4th International Workshop on RESTful Design (WS-REST 2013) at the 22nd International World Wide Web Conference (WWW2013), 2013, pp. 1415–1420 [slides].
Latest comments (0)