Blog

- March 02, 2015

Several years ago, while networking within the Open Source ecosystem in France, I met Jérôme Louvel with his Restlet Framework.  I’ve been following what he’s built on the theme of APIs ever since. Recently, I was blown away by what the amazing APISpark platform, the Restlet Studio for API design and DHC by Restlet for API testing have to offer to developers, as well as data producers and API consumers who need to access and expose their data to the world.

With Pivotal ending its commitment to funding the Groovy Open Source project, I took that as a hint that perhaps it was time for me to diversify a bit from my past 11 years working essentially on Groovy.  I wanted to learn and explore new things, and perhaps to apply Groovy into some novel and concrete scenarios that can be found in the world of APIs. That’s why I decided to join Restlet!

APIs, like Groovy, are also languages that are used by machines and applications to communicate between them! So there’s a common theme between those two topics for me! Within an API platform, I see interesting opportunities for using a language like Groovy for API design to be able to orchestrate APIs together, for defining some business logic rules or scripts to be triggered at regular intervals or upon certain events, or to further fine tune how these scalable web APIs should be exposed to the world with specific programmable logic.

In the post from Jérôme welcoming me to Restlet, I mentioned use cases where companies have been able to leverage Groovy to: orchestrate their cloud services like Alcatel-Lucent’s CloudBand Carrier PaaS or PayPal; enable user experience innovations at the API level like Netflix, as well as Netflix’ dynamic scripting platform;  tailor the Internet of Things to your needs like SmartThings; and scrape / clean / slice / dice / expose information for Open Data. There are many ways where languages meet with APIs, and there’s a world of interesting things to emerge out of that mix that can be discovered through the API design!

As part of Restlet, in the product leadership and developer advocacy teams, I’m looking forward to empowering developers and companies to realize the full potential of APIs, whether it is to simply exchange data with their partners, or to open data to the world, connect a mesh of objects together, and more.

 

Author: Guillaume Laforge

  • One thing I would say about future API development that I talk about with alot of companies is that the original pattern needs to change to abstract the communication logic/data away from business logic to allow for greater automation capabilities. Only through doing this can we create a shared IO state that all architectural instances can use, sync, update and version separate from functionality.

    Until then, we will continue to have the exact same issues we continue to have with the API pattern that we have as we scale it out.

    • For reference to our readers here, Owen’s got a great presentation on the topic here that he pushed on YouTube:

      • And yes, clean delineation and separation of concerns is always critical in our project architectures. The thing might be also about pragmatism, as to where to put the cursor exactly. An API isn’t just about CRUD over data, and we build functionality on top in a separate layer. You might think about things like triggers on value changes, or regular operations at certain times like “cron” operations, or you could also think of extending the underlying platform to allow a power-user mode where you go beyond simply tweaking some knobs to configure / manage your API, but by offering real “functions” defining those configuration values…
        Anyway, these ideas I have around this topic still need to mature, and I hope to be able to cover those themes in further blog posts here!
        I’d be happy to continue the conversation with you!

  • Heh. I would LOVE that conversation. I kid you not. These are the conversations that tickle my fancy and keep me up at night. Am integrating an HTML5 game just so I can start testing streaming data. 🙂

  • omigod! I see what your saying! So rather than just having webhooks that trigger off a change in the resource or when a function is called, have triggers that get called for a change in IO state or even functional state. So they can know if something has been reversioned or if data has changed and pull new values for automation. Its brilliant!

  • Pingback: Settimanale Groovy #60 | BME()

  • Johnnie Wallach

    Thoughtful article – I am thankful for the specifics ! Does anyone know if my business could possibly find a fillable CA FTB 540-ES copy to fill out ?