On behalf of the RAML Workgroup, I am excited to unveil the RESTful API Modeling Language today as an open spec. This project’s been under development for quite some time, while we’ve been battle testing it and utilizing it to improve our own internal APIs. As we began socializing the spec for feedback from several API experts, we were humbled to see mounting interest from folks who got deeply interested in collaborating on the direction of the spec. As a provider, an API is the capability you offer others (inside your company or outside) to derive your value, to add theirs, to create and realize opportunities. As a consumer, an API is what you build on to realize the provider's value or to generate even more value. So an API is a contract between provider and consumer, around an interface. Both the provider and the consumer have to build around a common definition for that API. The success of the API depends on how well this contract works, as well as how well it’s implemented on both sides. RAML is a language for expressing that interface, that contract, optimized for the users of the contract: the consumers and the providers.
There’s a saying that goes something like: to err is human, to really screw up big time takes a computer. But if you really want to have some fun, connect that computer to another computer, and you soon have a veritable nuclear chain reaction. The key to unlocking this energy? The lowly API, a programmer’s best friend, the little enabler that placed Google Maps in the center of mashup mania, drove the Ajax revolution, and is now generating over half of SalesForce.com’s revenues.
So, you’re a SaaS vendor and you want some API action for your service? Eager to get your share of the API Economy? Think you can just throw some @WebService annotations in your code and, blam-o, you’re now a card-carrying member of the API league? Not so fast…
An API is the set of "switches and levers" that a software service exposes so that other programs and services can interact with it. You can request data from the service through its API, and with the proper permissions you use the API to send data to the service. Various software programs have had APIs of one sort or another for decades. But with the advent of Software as a Service (SaaS), and the massive proliferation of SaaS providers and increasing granularization of their offerings, APIs have taken center stage in the value chain. It feels like every piece of software, every device, every thing either has an API or will soon have one. There's a growing realization of an entire API economy, with all the trimmings: providers of core services, aggregators, utility service providers, monetization plays, registries, and of course conferences and meetups, as well as trends and initiatives such as the consumerization of enterprise APIs. It's certainly a thrill ride now in the API space, and so many new developments to write about.