mca blog progressMon, 30 Nov 2015 00:35:54 GMTen-us180Microservice Style, 25 Nov 2015 00:08:00 GMT<blockquote> With apologies to <a href="">McIlroy, Pinson, and Tague</a>. </blockquote> <p> <a href=""> <img src="" width="150" align="right" class="inline" /> </a> </p> <p> A number of maxims have gained currency among the builders and users of microservices to explain and promote their characteristic style: </p> <p> <b>(i)</b> Make each microservice do one thing well. To do a new job, build afresh rather than complicate old microservices by adding new features. </p> <p> <b>(ii)</b> Expect the output of every microservice to become the input to another, as yet unknown, microservice. Don't clutter output with extraneous information. Avoid strongly-typed or binary input formats. Don't insist on object trees as input. </p> <p> <b>(iii)</b> Design and build microservices to be created and deployed early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. </p> <p> <b>(iv)</b> Use testing and deployment tooling (in preference to manual efforts) to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. </p>three keys to design-time governance: protocol, format, and vocabulary, 07 Nov 2015 17:11:00 GMT<p> <a href="" title="Three Keys"> <img src="" width="150" align="right" class="inline" /> </a> this is my ring of keys -- just three of them: work, home, car. i've been focusing over the last couple years on <i>reducing</i>. cutting back. lightening my load, etc. and the keys are one of my more obvious examples of success. </p> <p> i've also been trying to lighten my load <i>cognitively</i> -- to reduce the amount of things i carry in my head and pare things down to essentials. i think it helps me focus on the things that matter when i carry less things around in my head. that's me. </p> <p> staring at my keys today lead me to something that's been on my mind lately. something i am seeing quite often when i visit customers. the approach these companies use for governing their IT development lack the clarity and focus of my "three keys." in fact, most of the time as i am reading these companies' governance documents, they make me <i>wince</i>. why? because they're bloated, over-bearing, and -- almost all of them -- making things worse, not better. </p> <h4>over-constraining makes everyone non-compliant</h4> <p> i am frequently asked to provide advice on design and implementation of API-related development programs -- most often APIs that run over HTTP. and, in that process, i am usually handed some from of "<a href="">Design-Time Governance</a>" (DTG) document that has been written in-house. sometimes it is just a rough draft. sometims it is a detailed document running over 100 pages. but, while the details vary, there are general themes i see all too often. </p> <dl> <dt>Constraining HTTP</dt> <dd> almost every DTG approach i see lists things like HTTP methods (and how to use them), HTTP response codes (and what they mean), and HTTP Headers (including which new REQUIRED headers were invented for this organization). all carefully written. <b>and all terribly wrong</b>. putting limits on the use of standard protocols within your organization means every existing framework, library, and tool is essentially <i>non-compliant</i> for your shop. that's crazy. stop that! if your shop uses HTTP to get things done, just say so. don't try to re-invent, "improve", or otherwise muddle with the standard -- just use it. </dd> <dt>Designing URLs</dt> <dd> another thing i see in DTG documents is a section outlining the much-belabored and elaborate URLs design rules for the organization. Yikes! this is almost always an unnecessary level of "<a href="">bike-shedding</a>" that can only hold you back. designing URLs for your org (esp. large orgs) is a <a href="">fool's errand</a> -- you'll never get it right and you'll never be done with it. just stop. there are more than enough <a href="">agreed standards</a> on what makes up a valid URL and that's all you need to worry about. you should <a href="">resist the urge</a> to tell people how many slashes or dashes or dots MUST appear in a URL. it doesn't improve anything. <blockquote> look, i know that some orgs want to use URL design as a way to manage routing rules -- that's understandable. but, again, resist the urge to tell everyone in your org which URLs they can use for now and all eternity. some teams may not rely on the same route tooling and will use different methods. some may not use routing tools at all. and, if you change tooling after five years, your whole URL design scheme may become worthless. stop using URLs as your primary routing source. </blockquote> </dd> <dt>Canonical Models</dt> <dd> i really get depressed when i see all the work people put into negotiating and defining "<a href="">canonical models</a>" for the organization. like URL designs, <a href="">this always goes badly</a> sooner or later. stop trying to get everyone/every-team to use the same models! instead, use the same message formats. i know this is hard for people to grasp (i've seen your faces, srsly) but i can't emphasize this enough. there are several message formats <i>specifically designed</i> for data transfer between parties. use them! the only shared agreement that you need is the message format (along with the data elements carried <i>in</i> the message). </dd> <dt>Versioning Schemes</dt> <dd> here's one that just never seems to go away -- rules and processes for creating "new versions" of APIs. these things are a waste of time. <b>the phrase "new version" is a euphemism for "breaking changes" and this should never happen</b>. when you build sub-systems that are used by other teams/customers you are making a promise to them that you won't break things or invalidate their work (at least you SHOULD be making that promise!). it is not rocket-science to make backward-compatible changes -- just do it. once you finally accept your responsibility for not breaking anyone using your API, you can stop trying to come up w/ schemes to tell people you broke your promise to them and just get on with the work of building great software that works for a long time. </dd> </dl> <p> so, stop constraining HTTP, stop designing URLs, stop trying to dictate shared models, and forget about creating an endless series of breaking changes. "What then," you might ask, "IS the proper focus of design-time governance?" "How can I actually <i>govern</i> IT systems unless I control all these things?" </p> <h4>three keys form the base of design-time governance</h4> <p> ok, let me introduce you to my "three keys of DTG". these are not the ONLY things that need the focus on IT governance, but they are the <i>bare minimum</i> -- the essential building blocks. the starting point from which all other DTG springs. </p> <dl> <dt>Protocol Governance</dt> <dd> <p> first, all IT shops MUST provide protocol-level governance. you need to provide clear guidance and control over which application-level protocols are to be used when interacting with other parts of the org, other sub-systems, etc. and it is as simple as saying which protocols are REQUIRED, RECOMMENDED, and OPTIONAL. for example... </p> <p> "Here are BigCo, Inc. all installed components that provide an API MUST support <a href="">HTTP</a>. These components SHOULD also support <a href="">XMPP</a> and MAY also support <a href="">CoAP</a>. Any components that fail to pass this audit will be deemed non-compliant and will not be promoted to production." </p> <blockquote> you'll notice the CAPITALIZED words here. these are all special words taken from the IETF's <a href="">RFC2119</a>. they carry particular meaning here and your DTGs SHOULD use them. </blockquote> </dd> <dt>Format Governance</dt> <dd> <p> another <i>essential</i> governance element is the message formats used when passing data between sub-systems. again, nothing short of clear guidance will do here. and there is no reason to invent your own message-passing formats when there are so many good ones available. for example... </p> <p> "All API data responses passed between sub-systems MUST support <a href="">HTML</a>. They SHOULD also support one of the following: <a href="">Collection+JSON</a>, <a href="">HAL</a>, <a href="">Siren</a>, or <a href="">UBER</a>. sub-systems MAY also support responses in <a href="">Atom</a>, <a href="">CSV</a>, or <a href="">YAML</a> where appropriate. When accepting data bodies on requests, all components MUST support <a href="">FORM-URLENCODED</a> and SHOULD support request bodies appropriate for related response formats (e.g. Collection+JSON, Siren, etc.). Any components that fail to pass this audit will be deemed non-compliant and will not be promoted to production." </p> <blockquote> you'll notice that my sample statement does not include TXT, JSON or XML as compliant API formats. why? because all of them suffer the same problem -- they are insufficiently structured formats. </blockquote> </dd> <dt>Vocabulary Governance</dt> <dd> <p> the first two keys are easy. have a meeting, argue with each other about which existing standards are acceptable and report the reusults. done. but, this last key (<a href="">Vocabulary Governance</a>) is the hard one -- the kind of work for which enterprise-level governance exists. the one that will likely result in lots of angry meetings and may hurt some feelings. </p> <p> there MUST be an org-level committee that governs all the data names and action names for IT data transfers. this means there needs to be a shared dictionary (or set of them) that are the <i>final arbiter</i> of what a data field is <i>named</i> when it passes from one sub-system to the other. <a href="">managing the company domain vocabulary</a> is <b>the most important job of enterprise-level governance</b>. </p> <blockquote> the careful reader will see that i am not talking about governing <i>storage models</i> or <i>object models</i> here -- just the names of data fields passed within messages between sub-systems. understanding this is most <i>critical</i> to the success of your IT operations. models are the responsibility of local sub-systems. passing data <i>between</i> those sub-systems is the responsibility IT governance. </blockquote> </dd> </dl> <h4>what about all those "ilities"?</h4> <p> as i mentioned at the opening, these three keys form the <i>base</i> of a solid DTG. there are still many other <a href="">desirable properties</a> of a safe and healthy IT program including availability, reliability, security, and many more. this is not about an "either/or" decision ("Well, I guess we have to choose between Mike's three keys and everything else, right?" -- ROFL!). we can discuss the many possible/desirable properties of your IT systems at some point in the near future -- <i>after</i> you implement your baseline. </p> <p> so, there you have it. protocol, format, vocabulary. get those three right and you will be laying the important foundation for an IT shop that can retain stability without rigidity; that can adapt over time by adding new protocols, formats, and vocabularies without breaking existing sub-systems or ending up in a deep hole of <a href="">technical-debt</a>. </p> <h4>those are the keys to a successful design-time governance plan.</h4>dftw - decoupled for the win, 11 Oct 2015 23:51:00 GMT<p> <a title="By Daniel Schwen (Own work) [CC BY-SA 4.0 (], via Wikimedia Commons" href=""> <img width="150" alt="Train coupling" src="" align="right" class="inline"/> </a> it doesn't matter if your service is <a href="">"micro"</a> or <a href="">"oriented"</a>, if it's <a href="">tightly coupled</a> -- especially if your service is on the Web -- you're going to be stuck nursing your service (and all it's consumers) through <a href="">lots of pain</a> every time each little change happens (<a href="">addresses</a>, <a href="">operations</a>, <a href="">arguments</a>, <a href="">process-flow</a>). and that's just <a title="By from Tiverton, UK [CC BY-SA 2.0 (], via Wikimedia Commons" href="!_(3225490111).jpg">needless pain</a>. needless for you and for anyone attempting to consume it. </p> <h4>tight coupling is trouble</h4> <p> tight coupling to any external component or service -- what i call a <i>fatal dependency</i> -- is big trouble. you don't want it. run away. how do you know if you have a fatal dependency? if some service or component you use changes and your code breaks -- that's <b>fatal</b>. it doesn't matter what code framework, software pattern, or architectural style you are using -- breakage is fatal -- stop it. </p> <h4>the circuit</h4> <p> you can stave off fatalities by wrapping calls to dependents in what <a href="">Nygaard</a> calls in his book <a href="">Release It!</a> a <a href="">Circuit Breaker</a> but that requires you <i>also</i> have either 1) an alternate service provider (or set of them) or, 2) you write your code such that the unavailable dependency doesn't mean your code is essentially unusable (<i>"Sorry, our bank is unable to perform deposits today."</i>). and the Circuit Breaker pattern is not meant for use when services introduce <b>breaking changes</b> anyway -- it's for cases when the dependent service is <i>temporarily</i> unavailable. </p> <h4>a promise</h4> <p> you're much better off using services that make a promise to their consumers that any changes to that service will be non-breaking. IOW, changes to the interface will be only <i>additive</i>. no existing operations, arguments or process-flows will be taken away. this is not really hard to do -- except that existing tooling (code editors, build-tools, and testing platforms) make it really <i>easy</i> break that promise! </p> <blockquote> there are lots of refactoring tools that make it hard to break existing <i>code</i>, but not many focus on making it hard to break existing public <i>interfaces</i>. and it's rare to see testing tools that go 'red' when a public interface changes even though they are great at catching changes in private function signatures. bummer. </blockquote> <p>so you want to use services that keep the "no breaking changes" pledge, right? that means you also want to deploy services that make that pledge, too. </p> <h4>honoring the pledge</h4> <p> but how do you honor this "no breaking changes" pledge and still update your service with new features and bug fixes? it turns out that isn't very difficult -- it just takes some discipline. </p> <p>here's a quick checklist for implementing the pledge:</p> <dl> <dt>promise operations, not addresses</dt> <dd> service providers SHOULD promise to support a named operation (<code>shoppingCartCheckOut</code>, <code>computeTax</code>, <code>findCustomer</code>) instead of promising exact addresses for those operations (<code></code>). on the Web you can do that using properties like <code>rel</code> or <code>name</code> or <code>id</code> that have predetermined values that are well-documented. when this happens, clients can "memorize" the <i>name</i> instead of the address. </dd> <dt>promise message formats, not object serializations</dt> <dd> object models are bound to change -- and change often for new services. trying to get all your service consumers to learn and track all your object model changes is just plain wrong. and, even if you <i>wanted</i> all consumers to keep up with your team's model changes, that means your feature velocity is tied to the slowest consumer in your ecosystem - blech! instead, promise generic message formats that don't require an understanding of object models. formats like <a href="">VoiceXML</a> and <a href="">Collection+JSON</a> are specifically designed to support this kind of promise. <a href="">HTML</a>, <a href="">Atom</a>, and other formats can be used in a way that maintains this promise, too. clients can now "bind" for the messgae format, not the object model -- changes to the model on the service don't leak out to the consumer. when this happens, adding new data elements in the response will not break clients. </dd> <dt>promise transitions, not functions</dt> <dd> service providers SHOULD treat all public interface operations as message-based <i>transitions</i>, not fixed functions with arguments. that means you need to give up on the classic <a href="">RPC</a>-style implementation patterns so many tools lead you into. instead, publish operations that <i>pass messages</i> (using registered formats like <code>application/x-form-urlencoded</code>) that contain the arguments currently needed for that operation. when this happens, clients only need to "memorize" the argument names (all pre-defined in well-written documentation) and then pay attention to the transition details that are supplied in service responses. some "old skool" peeps call these transition details FORMs, but it doesn't matter what you call them as long as you promise to <i>use</i> them. </dd> <dt>promise dynamic process-flows, not static execution chains</dt> <dd> serivces SHOULD NOT promised fixed-path workflows ("I promise you will always execute steps X then A, then Q, then F, then be done."). this just leads consumers to hard code that nonsense into their app and break when you want to modify the workflow due to new business processes within the service. instead, services SHOULD promise a operation identifiers (see above) along with a limited set of process-flow identifiers (<code>start</code>, <code>next</code>, <code>previous</code>, <code>restart</code>, <code>cancel</code>, <code>done</code>) that work with <i>any</i> process-flow that you need to support. when this happens clients only need to "memorize" the generic process-flow keywords and can be coded to act accordingly. </dd> </dl> <h4>not complicated, just hard work</h4> <p> you'll note that all four of the above promises are not <a href="">complicated</a> -- and certainly not <a href=""><i>complex</i></a>. but they do represent some <a title="By J. Howard Miller, artist employed by Westinghouse, poster used by the War Production Co-ordinating Committee [Public domain], via Wikimedia Commons" href="!.jpg">hard work</a>. it's a bummer that tooling doesn't make these kinds of promises easy. in fact, most tools do the opposite. they make address-based, object-serialization with fixed argument functions and static execution chain easy -- in some tools these are the defaults and you just need to press "build and deploy" to get it all working. BAM! </p> <p> so, yeah. this job is not so easy. that's why you need to be diligent and disciplined for this kind of work. </p> <h4>eliminating dependencies</h4> <p> and -- back to the original point here -- decoupling addresses, operations, arguments, and process-flow means you eliminate lots of fatal dependencies in your system. it is now safer to make changes in components without so much worry about unexpected side-effects. and this will be a <b>big deal for all you microservice fans out there</b> because deploying dozens of independent services explodes your <i>interface-to-operation ratio</i> and it's just brutal to do that with tightly-coupled interfaces that <b>fail to support theses promises</b> inherent in a loosely-coupled implementation. </p> <h4>for the win</h4> <p> so, do not fear. whether you are a "microservice" lover or a "service-oriented" fan, you'll do fine as long as your make and keep these four promises. and, if you're a consumer of services, you now have some clear measures on whether the serivce you are about to "bind" to will result in fatalities in your system. </p>amazon, W3C and Tomorrow's Internet, 02 Oct 2015 21:36:00 GMT<p> <a href=""> <img src=";w=840&amp;h=485&amp;crop=1" align="right" class="inline" width="150"/> </a> i'll make this brief and to the point: </p> <p> Amazon's <a href="">decision</a> to bar Google- and Apple-tv products from its store is both disturibing and, IMO, an indication that the <a href="">W3C</a> is failing to live up to one of it's <a href="">key principles</a>. </p> <h4>Web For All</h4> <p> one of the key principles for W3C is the "Web for All" </p> <blockquote> The social value of the Web is that it enables human communication, commerce, and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability. </blockquote> <p> when a single vendor has the power to block others' access to competitive products, the Web is a place that doesn't live up to this principle. I know that <a href="">Tim Berners-Lee</a> is not <i>responsible</i> for the way Amazon operates. Neither is W3C CEO <a href="">Jeffery Jaffe</a>. however, this unfolding battle to pre-empt Web user's ability to access any content anywhere is just another iteration of the same battle that <a href="">timbl</a> (Berners-Lee's handle) has called out numerous times at the network level. what he calls the <a href="">Battle For The Net</a>. </p> <h4>users over all others.</h4> <p> i know the W3C has attempted to <a href="">deal with this</a> in the past -- to mixed reviews. the very fact that Tim penned that piece on DRM and the Web shows that the W3C is aware of the issue. and a key part of that (now two-year-old) position paper was the notion of <a href="">"users over all others"</a>: </p> <blockquote> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. </blockquote> <p> but events in this space seem to continue to run ahead of the W3C's ability to deal with them. and that's a big problem. </p> <h4>i know its hard, but it is important</h4> <p> i understand that the job of reigning in corporate greed on the open web is a tough job. and someone who has the best interests of users above all others needs to be <i>leading</i> the discussion. not following it. and certainly not silent while others establish the "operating rules" for yet another walled garden of profit built on the backbone of the free and <a href="">Open Web</a>. </p> <p> enabling commerce is a good thing. </p> <p> permitting exploitation and profiteering is not. </p> <h4>Tussle in Cyberspace</h4> <p> there is a great paper that deals with some of these issues: <a href="">Tussle in Cyberspace: Defining Tomorrow's Internet</a>. essentially: </p> <blockquote> This paper explores one important reality that surrounds the Internet today: different stakeholders that are part of the Internet milieu have interests that may be adverse to each other, and these parties each vie to favor their particular interests. We call this process “the tussle”. </blockquote> <p> the "tussle" is important. not because it <i>happens</i>, but because one of the key values of an open internet (not just Web) is that the Internet can be crafted (through standards) to "level the playing field" for all. this is why "Web For All" is important. this is why the Battle for the Net is important. </p> <p> and it is the same for video content, too. </p> <h4>why standards exist</h4> <p> we don't need to "regulate" vendors, we need to continue to make sure the tussle is fair to all. that's why standards exist -- <i>to level the playing field</i>. </p> <p> and, IMO, that's why the W3C exists. </p> <p> and that's why the current news is disturbing to me. </p>three years and counting, 30 Jun 2015 14:17:00 GMT<p> <a href="" title="API Academy"> <img src="" align="right" class="inline" /> </a> it was three years ago <a href="" title="Mike Amundsen, Principal API Architect">this month</a> that i joined <a href="" title="@MattMcLartyBC">Matt McLarty</a> and <a href="" title="@mitraman">Ronnie Mitra</a> to form the <a href="" title="API Academy">API Academy</a>. and i've never regretted a minute of it. </p> <h4>Layer7's brain child</h4> <p> the idea for the API Academy came out of the core leadership of what was then known as <a href="" title="Layer7">Layer7</a>. basically, it was the chance to pull together some of the great people involved in APIs for the Web and focus on promoting and supporting API-related technologies and practices. from the very beginning it was decided that the API Academy would focus on "big picture stuff" -- not a particular product or technology segment. and we dove in with both feet. </p> <p> my first talk <a href="">as part of the Academy</a> was June 2012 on hypermedia and node.js at QCon NYC. Ronnie and i finally met face-to-face later that summer at the Layer7 office in Vancouver. we both talked at <a href="">RESTFest 2012</a> where Layer7 became a key sponsor of that event. in December of 2012, Ronnie and I were proud to join <a href="" title="@medjawii">Mehdi Medjaoui</a> at the very first <a href="">API Days in Paris</a>. and we've been going strong ever since. </p> <h4>great people</h4> <p> the API Academy is an amazing group of people. over the last three years, along w/ Matt and Ronnie we've had the chance to host <a href="" title="@intalex">Alex Gaber</a>, <a href="" title="@hlgr360">Holger Reinhardt</a> -- both of whom have moved on to other things -- and <a href="" title="@inadarei">Irakli Nadareishvili</a> who came to us from his work at National Public Radio here in the US. the oppty to work side-by-side with people of this caliber is a gift and i am happy to be a part of it. </p> <h4>CA Technologies</h4> <p> since i joined API Academy, Layer7 has merged w/ <a href="" title="@CAInc">CA Technologies</a> and this has given us the chance to expand our reach and increase our contact w/ experienced people from all over the world. since joining w/ CA we've had the chance to travel to Australia, Hong Kong, Tokyo, Seoul, Beijing, and several cities Eastern Europe. later this year there will be visits to Shanghai and Rio de Janeiro along w/ dozens of cities in the US and Europe. along the way the API Academy continues to meet w/ CA product teams and leadership offering to assist in any way we can to continue the same mission we had at our founding. </p> <h4>Help People Build Great APIs for the Web</h4> <p> i've worked lots of places, with diverse teams, in all sorts of cultures. i have to say that my experience w/ the API Academy and w/ CA continues to be one of the most rewarding and supportive i've ever enjoyed. i am very lucky that i get to do the kind of work i love w/ people that challenge my thinking, support my experimenting, and offer excellent opportunities to learn and grow along the way. </p> <p> the last three years have been full of surprises and i can't wait to see what the next three years brings. i am truly a <i><b>#luckyMan</b></i> </p> the next level in Web APIs, 25 May 2015 21:07:00 GMT<p> <a href="" title="Description, Discovery, and Profiles : The Next Level in Web APIs"> <img src="" align="right" class="inline" width="150"/> </a> i'm very proud to announce that <a href="">InfoQ</a> has just released a new series that I helped edit. the series is called <a href="">Description, Discovery, and Profiles: The Next Level in Web APIs</a> and the contents of this series has a series of excellent contributing authors including <a href="" title="@mitraman">Ronnie Mitra</a> of <a href="">API Academy/CA</a>, <a href="" title="@mikegstowe">Mike Stowe</a> with <a href="">Mulesoft</a>, <a href="">Kin Lane</a> of <a href="">API Evangelist</a> fame and, <a href="" title="@fosrias">Mark Foster</a> from <a href="">Apiary</a>. it also includes interviews with <a href="">Swagger</a> creator <a href="" title="@fehguy">Tony Tam</a> and <a href="" title="">Profile RFC</a> editor <a href="" title="@dret">Erik Wilde</a>. and it's packed with material covering what i think are three key patterns/technologies in the Web API space: </p> <dl> <dt>Description</dt> <dd> "The ability to easily describe APIs including implementation details such as resources and URLs, representation formats (HTML, XML, JSON, etc.), status codes, and input arguments in both a human- and machine-readable form. There are a few key players setting the pace here." </dd> <dt>Discovery</dt> <dd> "Searching for, and selecting Web APIs that provide the desired service (e.g. shopping, user management, etc.) within specified criteria (e.g. uptime, licensing, pricing, and performance limits). Right now this is primarily a human-driven process but there are new players attempting to automate selected parts of the process." </dd> <dt>Profiles</dt> <dd> "Long a focus of librarians and information scientists, 'Profiles' that define the meaning and use of vocabulary terms carried within API requests and responses are getting renewed interest for Web APIs. Still an experimental idea, there is some evidence vendors and designers are starting to implement support for Web API Profiles." </dd> </dl> <h4>lots of vendors and technologies here</h4> <p> this is a pretty wide-ranging set of topics and lots of vendors and technologies are highlighted over the next seven articles. some of them include: </p> <ul> <li><a href="">Swagger</a></li> <li><a href="">RAML</a></li> <li><a href="">API Blueprint</a></li> <li><a href="">WSDL</a></li> <li><a href="">Visual Studio</a></li> <li><a href="">Eclipse</a></li> <li><a href="">SmartBear</a></li> <li><a href="">I/O Docs</a></li> <li><a href="">API Commons</a></li> <li><a href="">Programmable Web's API Directory</a></li> <li><a href="">3Scale</a></li> <li><a href="">Mashery's API Network</a></li> <li><a href="">Apache Zookeeper</a></li> <li><a href="">HashiCorp Consul</a></li> <li><a href="">CoreOS etcd</a></li> <li><a href=""></a></li> <li><a href="">XMDP</a></li> <li><a href="">DCAP</a></li> <li><a href="">ALPS</a></li> <li><a href="">Rapido API Designer</a></li> <li><a href="">Spring Data</a></li> <li><a href="">RDF</a></li> </ul> <p> and that's just in the <b>first</b> article in the series! </p> <p> here's a quick rundown of all the articles that will br released between late May and early July: </p> <h4>Description, Discovery, and Profiles: A Primer</h4> <p> this articles takes a look at several formats, key vendors, and identify the opportunities and challenges in this fast-moving portion of the Web API field. </p> <h4>From Doodles to Delivery : An API Design Process</h4> <p> Ronnie Mitra investigates what good design is and how using Profiles along with an iterative process can help us achieve it. </p> <h4>The Power of RAML</h4> <p> Mike Stowe introduces us to the RAML format, reviews avilable uses and tools, and explains why Uri Sarid, the creator of RAML wanted to push beyond our current understandings and create a way to model our APIs before even writing one line of code. </p> <h4>APIs with Swagger : An Interview with Reverb's Tony Tam</h4> <p> I talk to founder and inventor Tony Tam about the history, and the future, of one of the most widely-used API Description formats today: Swagger. </p> <h4>The APIs.json Discovery Format: Potential Engine in the API Economy</h4> <p> In this piece, Kin Lane describes his APIs.json API discovery format which can provide pointers to available documentation, licensing, pricing for exsiting Web APIs. </p> <h4>Profiles on the Web: An Interview with Erik Wilde</h4> <p> In early April, 2015 Erik agreed to sit down with InfoQ to talk about Profiles, Description, Documentation, Discovery, his Sedola project and the future of Web-level metadata for APIs. </p> <h4>Programming with Semantic Profiles : In the land of magic strings, the profile-aware is king.</h4> <p> Mark Foster -- one of the editors of the ALPS specification -- explains what semantic profiles are and how they can transform the way Web APIs are desgined and implemented. </p> <h4>A Resource Guide to API Description, Discovery, and Profiles</h4> <p> To wrap up the series, we offer a listing of the key formats, specifications, tools, and articles on API Description, Discovery, and Profiles for the Web. </p> <h4>looking forward to the weekly releases</h4> <p> it was a pleasure working with such a distinguished group of authors and practitioners in this very important space and i am looking forward to the continued released between late May and early July. i'm also looking forward to feedback and discussion from readers of the series. </p> <p> the Web is a dynamic and fast-moving space and it should be interesting to keep an eye on this "meta-level" of the API eco-system for some time to come. </p>RESTFest 2015 is Sep 17-19!, 12 May 2015 12:47:00 GMT<p> <img src="" align="right" class="inline" /> it's that time of year again! <a href="" title="RESTFest">RESTFest</a>, one of my favorite geek events of the year, will be happening (once again) in beautiful <a href="" title="Greenville, SC">Greenville, SC</a>. The dates of the event this year are Sep 17-19 and there are still <a href="" title="tickets">tickets</a> available. And this year's event is shaping up to be another great combo of hacking, demos, lighting talks and socializing. You can see what last year was like by checking out the <a href="" title="RESTFest 2015">2015 promo video</a>. </p> <h4>Keynote: IBM's James Snell</h4> <p> we're proud to announce that this year's keynote speaker is <a href="" title="@jasnell">James Snell</a>. i've known James for several years. he's a prolific man and has been involved in editing/authoring several IETF standards including the <a href="" title="RFC4287">Atom Syndication</a> format, the <a href="" title="RFC5789">HTTP PATCH</a> method, and the WC3's <a href="" title="Activity Streams 2.0">Activity Streams</a> spec. his keynote, <a href="" title="Practical Semantics">Practical Semantics</a>, is bound to be excellent. </p> <h4>the RESTFest way...</h4> <p> at RESTFest, we have a <a href="">core set of principles</a> that we think helps make for a unique and valuable experience for everyone involved. they boil down to... <dl> <dt>everybody talks</dt> <dd> if you show up, you're delivering a talk! our first principle is "everyone talks and everybody listens." for the past five years, we've stuck to a single track event and that allows everyone to hear *all* the talks, too. we all get to interact and experience the event in the same real-time space. </dd> <dt>less theory, more practice</dt> <dd> theories, formal papers, etc. etc. are all good, but we don't need them at RESTFest. we just want to hear what's on your mind, what you're working on, and what you are interested in talking about. show us your code! </dd> <dt>hacking is good</dt> <dd> day one is "hack day" and each year has a unique theme. anyone can propose a hackday theme and we encourage attendees to submit ideas and come prepared to code in whatever format, style, and framework they love. you can track and contribute to the <a href="">hackday</a> theme on the wiki. </dd> <dt>dont' be a jerk</dt> <dd> our <a href="">Code of Conduct</a> is very simple and very clear. essentially -- "Don't be a Jerk." it is critical that RESTFest be a safe, inviting, and positive experience for everyone. you're free to speak your mind as long as your respectful. </dd> </dl> if this sounds like something you'd enjoy, you're the right person for RESTFest. </p> <h4>Sign Up and Start Interacting NOW</h4> <p> actually, RESTFest has <a href="" title="RESTFest Wiki">already started</a>! right now you can sign up at the wiki, add your <a href="" title="People Pages">people page</a> and introduce yourself to the group. you can keep up on breaking news on our <a href="!forum/rest-fest" title="Google Groups">email list</a> and secure your place at the event by purchasing one of the limited <a href="" title="Tickets">tickets</a> for RESTFest 2015. if you're realy itching to get connected, drop into our <a href="">IRC channel</a> on freenode or link to our <a href="" title="@restfest">Twitter account</a> and start chatting. </p> <h4>RESTFest is what you want it to be</h4> <p> it's the people who show up each year that make RESTFest such a great event. each year is different and each year is amazing. check out our <a href="" title="RESTFest on Vimeo">video channel</a> to see all the talks from the last few years. spots are limited and we'd love to see you there! </p>Learning Client Hypermedia w/ O'Reilly, 26 Jan 2015 20:54:00 GMT<p> <a href="" title="Coding a Cj representor for my LCHBook project"> <img src="" align="right" class="inline" width="200"/> </a> it's official! i've signed an agreement w/ <a href="">O'Reilly Media</a> to write a book focused on creating hypermedia clients. i've been putting this project off for a couple years and am glad i finally will be sitting down to cull through the collected material and work to put it into a (hopefully) useful presentation. </p> <p> i've spent several weeks coding up lots of examples of hypermedia clients; experimenting with several existing media types and even some profiles. i've also been working through common patterns that make working w/ message-oriented services easier to handle for client apps. i have learned quite a bit over the last couple years of talking w/ people and assisting on various projects both large and small. and now it's time to see if i can find a coherent story in all that experience. </p> <p> <a href="">TBH</a>, i'm not <i>exactly</i> sure where this one will lead, but i have a decent plan to follow before i start out toward the horizon. i won't belabor the details here but will pass along my general outline to give folks a feel for where i am trying to go... </p> <h4>Part 1 : Human-Driven Hypermedia Clients</h4> <p> i'll be keeping discussions of human-driven and (i'll say) machine-driven clients clearly separated in the book. not because there is always a clear line between then in real life (think parsers designed to prefetch content based on inline instructions, etc.) but because it makes the conversation a bit easier. </p> <p> that said, the first part of the book will focus on the process of traveling from a client application that doesn't rely on <i>any</i> hypermedia, through several stages that end with a client that relies <i>primarily</i> on hypermedia information in responses. again, <a href="">IRL</a> there is a wide range of hypermedia in client apps for the Web (images anyone?) but this kind of approach will, i think, help bring some things into focus. </p> <h4>Part 2: Machine-Driven Hypermedia Clients</h4> <p> ahh, the fun stuff! the <a href="">holy grail</a>, the <a href="">unicorn</a> of song and story! </p> <p> or not. </p> <p> similar to part 1, i'll use the second half of the book to focus only on challenges related to creating hypermedia clients that don't rely directly on human intervention for each request. of course, humans will <i>program</i> them, but then -- at least for some level of interaction -- leave the machine to do their own thing. and that's where it gets fun. </p> <p> i'll talk about how we can build a client that has the power to do basic interaction (independent request/response), how machines can be "taught" to safely navigate a selected part of the WWW environment, how they can recognize 'things' (<a href="">affordances</a>) along the way, and how to use those things as tools to manipulate the local environment. finally, i'll talk about how a client can be taught to recognize a 'goal' or 'end-state.' </p> <p> in real life, humans do this kind of stuff every day. we navigate through traffic, recognize road signs/signals and are able to figure out when we reach our destination -- even if it is not the destination we had in mind at the start of our journey (<i>"Sorry mate, the pub is closed. But the one up the road is still open."</i>). we also go through these kind of scenarios in a more abstract or indirect way, such as when deciding we're done exercising, had enough to eat, or have collected enough trading cards to make a complete set. </p> <p> it turns out, none of the cases i mentioned above require much "intelligence" or "reasoning." just the ability to pay attention to details and identify "done." and there are very many instances where this level of execution would be useful over the Web today. unfortunately, even these simple kinds of machine execution are not often supported when implementing services for the Web -- and that's a bummer. </p> <p> but they <i>could</i> be. and that's cool. </p> <h4>On the Road Again</h4> <p> so, the next few months should be quite interesting. i always enjoy starting out on one of these adventures and this time is no different. i should also confess that i really enjoy getting to the end of a book project and <a href=""> putting the thing behind me</a> ;) and i suspect that will be the true this time, too. </p> <p> an added wrinkle is that i start traveling again in february and that usually takes a toll on deadlines. for that reason, i'll be drawing this project out a bit more. i hope to have the first draft completed by early summer and have it all wrapped up and out the door by fall 2015. </p> <p> so, here i go, getting ready to navigate toward the horizon and hopefully recognizing when i get to "done." </p> <p> should be exciting. </p> <p> <i>oops! road sign up ahead. gotta turn here. <a href="">L8TR</a>! </i> </p> 2014 Fall API Academy Pacific Tour, 17 Oct 2014 14:07:00 GMT<p> <a href="" title="luggage tags"> <img src="" width="150" align="right" class="inline"/> </a> yep - it's official! i'll be traveling the Pacific in late October and early November to present the <a href="" title="API Academy">CA API Academy</a> sessions on "How to Implement a Successful API Strategy." along the way, i'll be visiting the following cities: </p> <ul> <li> <a href="" title="Melbourne">Melbourne</a> (Oct-29) </li> <li> <a href=" " title="Sydney">Sydney</a> (Oct-30) </li> <li> <a href="" title="Hong Kong">Hong Kong</a> (Nov-04) </li> <li> <a href="" title="Tokyo">Tokyo</a> (Nov-05) </li> </ul> <h4>Rewriting Everything</h4> <p> i'm really excited about this trip because this time i am re-writing all my presentation content for the API Strategy Workshops. Instead of just collecting up the most popular content from our very successful <a href="" title="API Academy Services">API training program</a>, this time i am pulling together content from each of our incredibly talented <a href="" title="API Academy Team">API Academy team members</a> and highlighting the key insights each of them have on the major topics we're often asked when working with our customers. </p> <p> preparing this content is a real thrill for me because it's a chance to show people examples from the wide range of expertise and experience in the API Academy. it's also a bit duanting since i need to try to get up to speed on all the things our Academy folks have been working on in the last year. </p> <p>here's what i have planned for the upcoming workshops</p> <h4>Apps, APIs and the Enterprise: Enabling The Future of the Web </h4> <p> The growing explosion of <b>mobile devices</b> on the Web means <b>applications</b> will continue to become smaller and more numerous, <b>deployment</b> cycles will keep getting shorter, and the speed of <b>innovation</b> will increase. At the same time, <b>product teams</b> are getting smaller and more distributed making <b>project management</b> more challenging than ever. Succeeding in this constantly evolving environment requires more than speed, it takes <b>agility</b>, <b>planning</b>, <b>leadership</b> and the ability to act quickly and decisively. </p> <p> Join me for a half-day workshop where we explore: </p> <dl> <dt>Rewriting Business</dt> <dd>Refocusing your Business through Apps and the API Economy</dd> <dt>Rewriting Software</dt> <dd>Harnessing the Power of the Cloud and Mobile</dd> <dt>Rewriting Process</dt> <dd>Using DevOps to transform your Infrastructure</dd> <dt>Rewriting the Future</dt> <dd>Rethinking Governance and Reducing the Cost of Change</dd> </dl> <h4>Join Me!</h4> <p> it's going to be a great experience and i hope you will <a href="" title="API Academy Events">join me</a> as we review key business, software, process, and governance issues facing IT departments today and into the future. </p> <b><i>See you on the road!</i></b>mapping the api landscape, 21 May 2014 15:22:00 GMT<p> <a href="" title="Mapping the API Landscape"> <img src="" width="150" class="inline" align="right" /> </a> this week i had the opportunity to deliver a "lightning talk" at the <a href="" title=""> APIStrat Tech Un-Workshop </a> at <a href="" title=""> Gluecon 2014 </a>. the event was focused on two key topics: IoT and Service Description and Discovery. i was in the Service Description/Discovery track and delivered a talk called "<a href="">Mapping the API Landscape</a>" (<a href="">slides</a>). i won't cover the entire talk here (the text BTW has lots of links to information i could not discuss on stage this week) but did want to hit some key points. </p> <h4>what Google's self-driving car tells us</h4> <p> the "gCar" has been in <a href=""> the news again </a> and a key point that was disussed at some length in these articles was the fact that the car depends on a very detailed map of the roadways. in fact, the car currently can only drive in the Mountain View, CA area since that is the only landscape that is mapped well enough for the car to navigate. </p> <p> so, the Google car does not "discover" anything while drivig. it actually <i>recognizes</i> intersections, traffic lights, etc. through a special representation of the landscape that contains all the right annotations. this reliance on a known map allows the car to navigate successfully between two points within that landscape. this is no simple feat, of course. reacting to surroundings "at speed" takes serious computing power and that's one of the things that makes the Google implementation so amazing. </p> <h4>Norman's Action Lifecycle</h4> <p> the process of navigating from A to B is a goal-driven process that we see very often in nature. ants, micro-organisms, etc. all do this. <a href="">HCI</a> expert, <a href="" title="@jnd1er">Donald Norman</a> calls this process the Action Lifecycle or <a href=""> Seven Stages of Action </a>. </p> <p> this is how we learned to write GUI intefaces, too. wait for a keystroke or button-click, process that action, affect the UI, then allow the user to evaluate the changes and decide if another action is needed. we build Web servers like this, too. wait for a request, process it, modify the back-end (if needed) and reflect results back to the requestor. game programming works like this, too. but it's rare to see "Web Clients" written this way. they continue to look like single-minded bots that just "go from A to B" and ignore landmarks; incapable of actually reacting to surroundings. </p> <h4>client apps and web maps</h4> <p> why are most web client apps "one-off" implementations that are likely to break over time? because client dev's don't have decent "maps" of the Web landscape. and good maps are not just "photos" of the surroundings, but heavily annotated representations with recognizable symbols and landmarks. most servers today just belch out JSON or XML with almost no recognizable symbols or signage (e.g. hypermedia controls, etc.). </p> <p> so what we need to do is create maps for devs to use so that they can build their own client applications and solve their own problems. client apps should be free to follow whatever route within that map that they wish -- not just follow the path that server developers decide upon. </p> <h4>let's make maps!</h4> <p> things like Service Description formats, and discovery protocols are all ways to start creating more maps for client devs to rely upon. using hypermedia in responses provides the symbols and signs client apps can use at runtime (like the Google car) in order to navigate in realtime. </p> <p> there are several description formats (see my paper <a href=""> Hold your Nose vs. Follow your Nose </a> for more on this). in the book, <a href="">RESTful Web APIs</a> <a href="" title="@leonardr">Leonard Richardson</a> and i <a href=""> list close to 20 </a> options for expressing hypermedia in Web responses. and more have come online since the book was published last year. </p> <p> we have all we need. we just need to make more maps! </p>