Mike amundsen
|
As API Architect at Layer 7 Technologies, Mike Amundsen heads up the company's API Architecture & Design Practice in North America. He is responsible for working with companies to provide insight into how best to capitalize on the myriad opportunities APIs present to both consumers and the enterprise. An internationally-known author and lecturer, Amundsen is a recognized industry expert on subjects including distributed network architecture, Web application development and cloud computing. His recent work focuses on the role hypermedia plays in creating and maintaining applications that can successfully evolve over time. He has more than a dozen books to his credit, his book Building Hypermedia APIs with HTML5 & Node is often used as reference material in companies around the world. He is currently working on a new book with Leonard Richardson titled RESTful Web APIs. |
|
| Title | Describing the Possible with ALPS |
|---|---|
| Level | Moderate/Advanced (Extended Talk or Five-In-Five) |
| Abstract |
Now that the use of hypermedia is gaining traction, there is also a renewed interest in other ways to describe interactions between client and server. Some well-known examples are WSDL (2001), Atom Service Documents (2007), and WADL (2009). Few of these have gained wide adoption (outside the enterprise) but they are still seen in the wild and discussed online. Now there is a new set of description formats appearing including Swagger (2010?), RESTDesc (2011), ioDocs (2012), API Blueprint (2013), JSON-Home (2013), RSDL (2013) and even JSON Hyper-Schema (2013). All these designs have cropped up with the last year or so. What is it that all these attempts have in common? And why do we continue to generate new IDL-like formats for the same general purpose - to describe Web interfaces? Maybe it is because these formats are attempting to describe the wrong thing. What if, instead of describing the details of a particular instance of a service, there was an IDL format that described the service possibilities within a problem domain? What if we could describe all the possible data elements and actions without having to commit to ensuring each and every possible resource for an implementation? What if we could decouple describing the domain from describing the implementation details? This talk covers the Application-Level Profile Semantics or ALPS (2013) IDL format. ALPS is designed to describe problem domains in ways that allow both client and server to "understand" and "code-for" all the possible transitions and data elements without having to constrain a server to a single workflow or implementation. ALPS is both protocol- and media type-agnostic; you can use the same IDL document to implement the solution using HTML for HTTP and Siren for WS. Servers are free to create their own solutions within the problem domain with a high degree of confidence and any client that also understands the same ALPS description will be able to successfully interact with that server - even if they have never "met" each other before. Is this possible? Does it solve a real problem? Let's find out! |
| Supplemental | |
| Slides | Describing the Possible with ALPS. |