mca blog

been a long time...

Fri, 11 Nov 2022 14:42:00 GMT

been quite a while since i blogged here.

let's see if this gets picked up by feediverse and posted to my mastodon instance account.

who knows. this might get to be a habit again...

API Strategy at Mulesoft in 2019

Mon, 03 Jun 2019 15:52:00 GMT

i'm happy to announce that, starting in June of this year, I'll be working as an API Strategy Advisor with Mulesoft. this gives me a chance to team up w/ my long-time friend and colleague, Matt McLarty and to renew acquaintances w/ a handful of really talented and experienced API professionals at Mulesoft.

API Strategy

Matt and I (along with Irakli and Ronnie) worked together on the Microservices Architecture book and it will be good to be working with him again. that book, and a more recent one -- Continuous API Management (with Mehdi and Erik) -- focus on the steps beyond API as a "thing" and reflect a trend i see growing in the API community. that trend is to view APIs as a strategy for accomplishing business objectives.

as few as five years ago just having an API program could set you apart from your competition in the market. however, that is no longer the case. now, it is important the APIs that you spend you time and money to build, test, deploy, and support actually provide a measurable business advantage. that's where an API Strategy comes into play.

and companies that can enable that API Stratgey -- companies that not only understand it but can also help others adopt it -- are the companies i am anxious to work with, share, and learn from. and that is why today i am honored and excited to be able to begin working with Mulesoft and promote this "next level" approach to APIs.

MuleSoft Connect

over the coming weeks and months, Matt and I will be working to collect and share API Strategy experiences from companies of all sizes from around the world. we'll be taking the time to meet with and talk to industry leaders as well as promising startups in order to learn how they are using APIs to go to the "next level" and we'll be working to conslidate and share their knowledge and experience at events across the globe.

along these lines, Mulesoft will be hosting a series of events -- Mulesoft CONNECT -- at cities in North America, Europe, and Asia. Matt and I will be at the next CONNECT event in San Francisco later this month. you can also check the ongoing schedule to see when we'll be at a city near you. i'm looking forward to these opportunities to share and learn about the role API Strategy is playing in the community and hope to see you there.

2019 and Beyond

of course, strategy is just one step in the process of identifying, implementing, evaluating, and improving your organization's business and the IT ecosystem that supports it. and this is not an overnight process. it takes time, persistence, dedication, and patience. i'm excited to be able to join Mulesoft in helping promote this approach and looking forward to seeing how it can advance to role of APIs in businesses worldwide not just this year but also for many years to come.

Preserving the Egg on the Web

Sat, 31 Mar 2018 12:32:00 GMT

When I plan out an implementation for the Web, one of the things I think about is the problem of "breaking eggs." One great example of this is the old adage, "You can't make an omelette without breaking some eggs." That's cute. It reminds us that there are times in our lives when we need to commit. When we need to forge ahead, even if some people might disagree, even if there seems to be "no turning back."

However, this "omelette" adage is not what I mean when I think about Web implementations and eggs.

Instead, I think about entropy and how you cannot 'unscramble' an egg. I won't go into the physics or philosophical nuances of this POV except to say, when I am working on a web implementation I work very hard to avoid 'breaking any eggs' since it will be quite unlikely that I'll ever be able to put those eggs back together again.

I don't want my Web solution to end up like Humtpy Dumpty!

Web Interactions as Eggs

The web is a virtual world. It is a highly-distributed and non-deterministic -- much like our physical world. We can't know all the influences and their effects on us. We can only know our immediate surroundings and surmise the influences based on what we observe locally. The world is a random place.

So each time we fill out a form and press "send", each time we click on a link, we're taking a risk and stepping into the unknown. For example:

Is there really a page at the other end of this link or is there a dreaded 404 waiting for me at the other end?
Have I filled out the form correctly or will I get a 400 error instead?
Or, have I filled out the form correctly, only to encouter a 500-level server error?
Finally, what if I've filled out the form, pressed "send" and never get a response back at all? what do I do now?

But What Can Be Done?

When I set out to implement a solution on the Web, I want to make sure to take these types of outcomes into account. I say "take them into account" because the truth is that I cannot prevent them. Most of the time these kinds of failures are outside my control. However, using the notion of Safety-I and Safety-II from Erik Hollnagel, I can adopt a different strategy: While can't prevent system failures, I can work to survive them.

So how can I survive unanticipated and un-preventable errors in system? I can do this by making sure each interaction is not an "egg-breaking" event. An "egg-breaker" is an action that cannot be un-done, cannot be reversed. In the web world, this is an interaction that has only two outcomes: "success or a mess."

A great example of the sad end of the "success-or-a-mess" moment is an action like "Delete All Data." We've probably all experienced a moment like this. Most likely we've answered "yes" or "OK" to a confirmation dialog and the moment we did, we realized (too late) that we "chose poorly." There was no easy way to fix our mistake. We had a mess on our hands.

The obvious answer to this kind of mess is to support an "undo" action to reverse the "do." This turns an "egg-breaking" event into and "egg-preserving" event. And that's what I try to do with as much of my Web implementations as possible -- preserve the egg.

Let's look at some other ways to prevent breaking eggs when implementing solutions in a non-deterministic world...

Network-Level Idempotency

One of the ways you can avoid "a mess" is to make sure your actions are idempotent at the network level. That means they are repeatable and you get the same results every time. Think of an SQL UPDATE statement. You can update the the firstName field with the value "Mike" over and over and the firstName field will always have the same value: "Mike".

In the HTTP world, both the PUT and DELETE methods are designed as idempotent actions. This means, in cases where you commit a PUT and never recieve a response, you can repeat that action without worry of "breaking the egg."

Relying on network-level idempotency is very important when you are creating autonomous services that interact with each other without direct human intervention. Robots have a hard time dealing with non-idempotent failures.

Service-Level Event Sourcing

At the individual service level, a good way to "preserve the egg" is to make all writes (actions that change that state of things) reversible. Martin Fowler shows how this can be done using Event Sourcing. Event Sourcing was explained to me by Capital One's, Irakli Nadareishvili as a kind of "debit-and-credit" approach to data updates. You arrange writes as actions that can be reversed by another write. Essentially, you're not "un-doing" something, you're "re-doing" it.

Fowler shows that, by implementing state changes using Event-Sourcing, you get several benefits including:

detailed change logs
the ability to run a complete rebuild
the ability to run a "temporal query" (based on a set date/time)
the power to replay past transctions (to fix or analyze system state)

I like say that, with Event-Sourcing, you can't reverse the arrow of time, but you can move the cursor.

Solution-Level Sagas

In 1987, Garcia-Molina and Salem published a paper simply titled "Sagas." This paper describes how to handle long-lived transactions in a large-scale system where the typical Two-Phase Commit pattern results in a high degree of latency. Sagas are a another great way to keep from "breaking the egg."

Chris Richardson has done some excellent work on how to implement Sagas. I like to think of Sagas as a way to bring the service-level event-sourcing pattern to a solution-level of multiple interoperable services. Richardson points out there is more than one way to implement Sagas for distributed systems including:

Choreography-based (each service publishes their own saga events)
Orchestration-based (each saga is managed by a central saga orchestrator)

Sagas are a great way to "preserve the egg" when working with multiple services to solve a single problem.

And so...

When putting together your Web implementations, it is important to think about "preserving the egg" -- making sure that you can reverse any action in case of an unexpected system failure. Working to avoid "breaking the egg" adds a valuable level of resilience to your implementations. This can protect your services, your data, and your users from possibly catastrophic events that lead to "a mess" that is difficult and costly to fix.

In this post, I shared three possible ways to do this at the network, service, and solution level. There are probably more. The most important thing to remember is that the Web is a highly-distributed, non-deterministic world. You can't prevent bad things from happening, but with enough planning and attention to details, you can survive them.

now that this post is done, anyone hungry for an omelette?

Model Actions, Not Data

Tue, 13 Feb 2018 22:40:00 GMT

I've not blogged in quite a while here -- lots of reasons, none of them sufficient. So, today, i break the drought with a simple rant. Enjoy -- mca

It is really encouraging to see so many examples of companies and even industries spending valuable resources (time, money, people) on efforts to define, implement, and advocate for "open" APIs. in the last few years i've seen a steady rise in the number of requests to me for guidance on how to go about this work of creating and supporting APIs, too. And i hear similar stories from other API evangelists and practitioners up and down the spectrum from startups to multi-nationals. And, like i said, it is encouraging to see.

But…

Even though i've been quite explicit in my general guidance through lots of media and modes (interviews, presentations, even full-length books), it is frustrating to see many people continue to make the same simple mistakes when going about the work of designing and deploying their APIs. so much so, that i've decided to "dis-hibernate" this blog in order to squawk about it openly.

And chief among these frustrations is the repeated attempts to design APIs based on data models. Your database is not your API! Stop it. Just stop.

Unless you are offering API consumers a SaaS (storage-as-a-service) you SHOULD NOT be using your data model as any guide for your API design. Not. At. All.

Arthur Jensen (In a loud, angry voice): "You are messing with the primal forces of nature Mr. Beale. And YOU! WILL! ATTONE!"

(Arthur pauses and leans in to whisper in Beale's ear)

Arthur: "Am I getting through to you, Mr. Beale?"

Network (1976)

When you cast about for a handle on how to go about designing your API, the answer is straightforward and simple: Model your Actions.

It can't be stated any more directly. Model your Actions.

Don't get caught up in your current data model. Don't fall down the rabbit hole of your existing internal object model. Just. don't.

Need more? Here's a handy checklist:

Start with a list of actions to be completed. (Jobs To Be Done) -- if that sparks your brain.
Determine all the data elements that must be passed when performing that action.
Identify all the data elements to be returned when the action is performed. Be sure to account for partial or total failure of the attempted action.
Rinse and repeat.

Leonard Richardson and I offer up a long-form description of this four-step plan in our book "RESTful Web APIs".

Once you feel good about your list of actions and data points (input and output), collect related actions together. Each collection identifies a context. A boundary for a component. That might sound familiar to some folks.

Now you have an API to implement and deploy. When implementing this API, you can sort out any object models or data models you want to use (pre-existing or not). But that's all hum-drum implementation detail. Internal stuff no one consuming the API should know or care about.

All they care about are the possible actions to perform. And the data points to be supplied and returned.

That's it. Simple.

Of course, simple is not easy.

"I would have written a shorter letter but I just didn't have the time."

-- various attributions.

now, if a simple rant is not enough, i offer up an epigram i first shared publicly back in 2016:

remember, when designing your #WebAPI, your data model is not your object model is not your resource model is not your message model #API360

@mamund

And if a single epigram is not motivation enough, how about a whole slide deck from APIStrat 2016 devoted to explaining that simple phrase?

Now, armed (again) with this clear, simple advice, you're ready to avoid the debacle of data-centric industry-wide APIs.

just go out there and take action (not data)!

an online tutorial -- with friends

Tue, 02 Feb 2016 21:22:00 GMT

there just a few days left before my live O'Reilly Implementing Hypermedia online tutorial on february 9th (11AM to 5PM EST). and i'm spending the day tweaking the slides and working up the six hands-on lessons. as i do this, i'm really looking forward to the interactive six hour session. we'll be covering quite a bit in a single day, too.

the agenda

most of the material comes from my 2011 O'Reilly book Building Hypermedia APIs with HTML5 and Node. however, i've added a few things from RESTFul Web APIs by Leonard Richardson and even brought in a few items from my upcoming book RESTful Web Clients.

the high-level topics are:

Designing a Hypermedia API
Using the DORR Pattern for Coding Web APIs
Understanding the Collection+JSON Media Type
Building Hypermedia SPA Clients

by the time the day is done, everyone will have a fully-functional Hypermedia API service up and running and a Cj-compliant general-pourpose hypermedia client that works w/ ANY Web API that supports the Collection+JSON media type.

Greenville Hypermedia Day

the tutorial is geared toward both individual and team participation. i know some companies are arranging a full-day session with their own dev teams for this, too. and i just heard about a cool event in Greenville, SC for people who want to get the "team" spirit...

i found out that Benjamin Young is hosting a Hypermedia Day down in Greenville, SC on feb 9th. If you're in the area, you can sign up, show up, join the tutorial in progress, and chat it up w/ colleagues. I know Benjamin from our work together for RESTFest and he's a good egg w/ lots of skills. He'll be doing a Q&A during the breaks in the tutorial modules and i think he might have something planned as an "after-party" thing at the end of the day.

if you're anywhere near Greenville, SC on feb-09, you should join Benjamin's Hypermedia Day festivities!

cut me some slack

i know most of the attendees are going "solo" -- just you, me, and the code -- that's cool. O'Reilly is hosting a live private Slack channel for everyone who signs up for the tutorial. I'll be around all day (and probably some time after that, too) so we can explore the exercises, work out any bugs, and just generally chat.

it's all ready!

so, as i wrap up the slides, the hands-on lessons, the github repo, and the heroku-hosted examples, i encourage you to sign up and join us for a full day of hypermedia, NodeJS, and HTML5.

see you there!

Dallas is my first stop in 2016

Thu, 07 Jan 2016 17:56:00 GMT

the week of january 11th i'll be in Dallas for two events. this is my first trip of 2016 and i'm looking forward to catching up w/ my Dallas peeps. I'll be visiting with the great folks at DFW API Professionals on Jan-13 and addressing a gathering of Dallas-area IT dignitaries at AT&T Stadium during the day on the 14th.

DFW API Professionals

i've known Traxo's Chris Stevens for several years and, when i learned i would be in Dallas in January, we were able to arrange an oppty for me to address his meetup group: DFW API Professionals. I'll be talking about and demoing hypermedia API client coding patterns and taking questions, too. check out the event and, if you can, join me and the whole DFW API Pro membership.

API Management Best Practices Discussion

on thursday, i'll be at the AT&T Stadium with my fellow CA colleagues and folks from Perficient to join in the discussion on API mgmt and a look into the near future. i get to share the podium w/ CA SVp and Distinguished Engineer, Scott Morrison. in a lively open discussion (no slideware), we'll be covering API design, deployment, DevOps, Microservices, and IoT with Perficient's Director of Emerging Platform Solutions, Annel Adzem. stellar conversation, stunning view of the field -- what's not to like?

just the beginning

of course, this is just the start of my travels for 2016. i've already got the cities of Vancouver, Washington DC, E. Brunswick, Seoul, Tokyo, Melbourne, Sydney, San Francisco, Sao Paulo, Rio, Buenos Aries, and New York on my agenda. and that's just the first few months of 2016!

gonna be another great year with the API Academy! if you're anywhere near those cities, keep in touch and i hope we meetup sometime soon.

Microservice Style

Wed, 25 Nov 2015 00:08:00 GMT

With apologies to McIlroy, Pinson, and Tague.

A number of maxims have gained currency among the builders and users of microservices to explain and promote their characteristic style:

(i) Make each microservice do one thing well. To do a new job, build afresh rather than complicate old microservices by adding new features.

(ii) 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.

(iii) 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.

(iv) 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.

three keys to design-time governance: protocol, format, and vocabulary

Sat, 07 Nov 2015 17:11:00 GMT

this is my ring of keys -- just three of them: work, home, car. i've been focusing over the last couple years on reducing. cutting back. lightening my load, etc. and the keys are one of my more obvious examples of success.

i've also been trying to lighten my load cognitively -- 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.

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 wince. why? because they're bloated, over-bearing, and -- almost all of them -- making things worse, not better.

over-constraining makes everyone non-compliant

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 "Design-Time Governance" (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.

Constraining HTTP: 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. and all terribly wrong. putting limits on the use of standard protocols within your organization means every existing framework, library, and tool is essentially non-compliant 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.
Designing URLs: 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 "bike-shedding" that can only hold you back. designing URLs for your org (esp. large orgs) is a fool's errand -- you'll never get it right and you'll never be done with it. just stop. there are more than enough agreed standards on what makes up a valid URL and that's all you need to worry about. you should resist the urge to tell people how many slashes or dashes or dots MUST appear in a URL. it doesn't improve anything.
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.
Canonical Models: i really get depressed when i see all the work people put into negotiating and defining "canonical models" for the organization. like URL designs, this always goes badly 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 specifically designed for data transfer between parties. use them! the only shared agreement that you need is the message format (along with the data elements carried in the message).
Versioning Schemes: 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. the phrase "new version" is a euphemism for "breaking changes" and this should never happen. 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.

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 govern IT systems unless I control all these things?"

three keys form the base of design-time governance

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 bare minimum -- the essential building blocks. the starting point from which all other DTG springs.

Protocol Governance

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...

"Here are BigCo, Inc. all installed components that provide an API MUST support HTTP. These components SHOULD also support XMPP and MAY also support CoAP. Any components that fail to pass this audit will be deemed non-compliant and will not be promoted to production."

you'll notice the CAPITALIZED words here. these are all special words taken from the IETF's RFC2119. they carry particular meaning here and your DTGs SHOULD use them.

Format Governance

another essential 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...

"All API data responses passed between sub-systems MUST support HTML. They SHOULD also support one of the following: Collection+JSON, HAL, Siren, or UBER. sub-systems MAY also support responses in Atom, CSV, or YAML where appropriate. When accepting data bodies on requests, all components MUST support FORM-URLENCODED 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."

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.

Vocabulary Governance

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 (Vocabulary Governance) 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.

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 final arbiter of what a data field is named when it passes from one sub-system to the other. managing the company domain vocabulary is the most important job of enterprise-level governance.

the careful reader will see that i am not talking about governing storage models or object models here -- just the names of data fields passed within messages between sub-systems. understanding this is most critical to the success of your IT operations. models are the responsibility of local sub-systems. passing data between those sub-systems is the responsibility IT governance.

what about all those "ilities"?

as i mentioned at the opening, these three keys form the base of a solid DTG. there are still many other desirable properties 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 -- after you implement your baseline.

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 technical-debt.

those are the keys to a successful design-time governance plan.

dftw - decoupled for the win

Sun, 11 Oct 2015 23:51:00 GMT

it doesn't matter if your service is "micro" or "oriented", if it's tightly coupled -- especially if your service is on the Web -- you're going to be stuck nursing your service (and all it's consumers) through lots of pain every time each little change happens (addresses, operations, arguments, process-flow). and that's just needless pain. needless for you and for anyone attempting to consume it.

tight coupling is trouble

tight coupling to any external component or service -- what i call a fatal dependency -- 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 fatal. it doesn't matter what code framework, software pattern, or architectural style you are using -- breakage is fatal -- stop it.

the circuit

you can stave off fatalities by wrapping calls to dependents in what Nygaard calls in his book Release It! a Circuit Breaker but that requires you also 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 ("Sorry, our bank is unable to perform deposits today."). and the Circuit Breaker pattern is not meant for use when services introduce breaking changes anyway -- it's for cases when the dependent service is temporarily unavailable.

a promise

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 additive. 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 easy break that promise!

there are lots of refactoring tools that make it hard to break existing code, but not many focus on making it hard to break existing public interfaces. 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.

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.

honoring the pledge

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.

here's a quick checklist for implementing the pledge:

promise operations, not addresses: service providers SHOULD promise to support a named operation (shoppingCartCheckOut, computeTax, findCustomer) instead of promising exact addresses for those operations (http://myservice.example.org/findCustomer). on the Web you can do that using properties like rel or name or id that have predetermined values that are well-documented. when this happens, clients can "memorize" the name instead of the address.
promise message formats, not object serializations: 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 wanted 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 VoiceXML and Collection+JSON are specifically designed to support this kind of promise. HTML, Atom, 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.
promise transitions, not functions: service providers SHOULD treat all public interface operations as message-based transitions, not fixed functions with arguments. that means you need to give up on the classic RPC-style implementation patterns so many tools lead you into. instead, publish operations that pass messages (using registered formats like application/x-form-urlencoded) 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 use them.
promise dynamic process-flows, not static execution chains: 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 (start, next, previous, restart, cancel, done) that work with any 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.

not complicated, just hard work

you'll note that all four of the above promises are not complicated -- and certainly not complex. but they do represent some hard work. 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!

so, yeah. this job is not so easy. that's why you need to be diligent and disciplined for this kind of work.

eliminating dependencies

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 big deal for all you microservice fans out there because deploying dozens of independent services explodes your interface-to-operation ratio and it's just brutal to do that with tightly-coupled interfaces that fail to support theses promises inherent in a loosely-coupled implementation.

for the win

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.

amazon, W3C and Tomorrow's Internet

Fri, 02 Oct 2015 21:36:00 GMT

i'll make this brief and to the point:

Amazon's decision to bar Google- and Apple-tv products from its store is both disturibing and, IMO, an indication that the W3C is failing to live up to one of it's key principles.

Web For All

one of the key principles for W3C is the "Web for All"

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.

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 Tim Berners-Lee is not responsible for the way Amazon operates. Neither is W3C CEO Jeffery Jaffe. 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 timbl (Berners-Lee's handle) has called out numerous times at the network level. what he calls the Battle For The Net.

users over all others.

i know the W3C has attempted to deal with this 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 "users over all others":

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

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.

i know its hard, but it is important

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 leading 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 Open Web.

enabling commerce is a good thing.

permitting exploitation and profiteering is not.

Tussle in Cyberspace

there is a great paper that deals with some of these issues: Tussle in Cyberspace: Defining Tomorrow's Internet. essentially:

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”.

the "tussle" is important. not because it happens, 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.

and it is the same for video content, too.

why standards exist

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 -- to level the playing field.

and, IMO, that's why the W3C exists.

and that's why the current news is disturbing to me.