mca blog

if they have to ask, you didn't afford it.

Sat, 16 Mar 2013 20:10:00 GMT

my guess is you are familiar with the phrase: "If you have to ask, you can't afford it." that's not what i mean here. let me show you...

if they have to ask...

try this:

create a new Web API
implement it on some server - up and running
hand the a single URL to some client dev and say "there ya go!"

is the API self-descriptive? does it contain enough information in the responses to allow client devs to know what the API is for, what it is capable of, and how client devs can make valid requests to the server and properly parse the responses?

here are some questions for you...

how many assumptions do you have about your API?
are these assumptions shared by client devs?
all clients devs?
even ones who have never met you?

if the answer to any of those questions is "no" or "i am not sure" then it is likely that someone will need to ask you questions about how to properly use your API. that's no big deal, right?

...you didn't afford it

in everyday life, if people have to ask how to use a device (television remote, toaster, etc.) then you can be sure that device is "poorly afforded" - it's a weak design. we all know devices (esp. electronics) that come with huge manuals and complicated explanations - bummer.

in this respect, your API is the same as any other consumer device. it should be "well afforded." developers should not have to read the technical equivalent of Tolstoy's "War and Peace" before they can successfully use your API.

yes, you can supply detailed instructions in prose, provide a long list of possible methods, include lots of tables, etc. these are helpful for devs, but they can be daunting to read and cumbersome to maintain.

another approach is the include this kind of information in a machine-readable format. one that most devs will also understand quickly. a set of instructions that get automatically updated whenever your API changes - hypermedia controls in the response. why write a web page of documentation to tell devs to construct a URI and use that URI to execute an HTTP GET when you can just include that (and much more) in your API responses?

help your client devs out. throw 'em a bone, here. don't make them read pages of docs when you can just include the simple run-time instructions instead.

in conclusion

if they have to ask, you didn't afford it.

representation vs. description

Fri, 01 Mar 2013 08:01:00 GMT

over the last few months i've been working w/ Leonard Richardson on a book. along the way we've been collecting lots of ideas, assessing how things have worked out over the years, etc.

one of the things that has come up several times -- so much that it will likely be covered in the book -- is the idea that some Web patterns are focused, not on representing the state of things on a server but actually designed to describe the things on a server. this may seem like a subtle, possibly meaningless difference. but as i go through various technologies, guidance, and implementation examples, i think this way of viewing efforts on the Web today (representing vs. describing) is important. and mixing them up can cause you unnecessary pain.

what is happening?

representing the state of things on a server is what most of us assume the Web is all about. "I'll just go to that Web page and see if my order has been shipped." or "Gee, I wonder where that movie I want to see is playing this weekend?" and so forth. we use the Web to see what is happening, what has happened, even with will happen at some future point.

most of the applications built for the Web fall into this same category. we want to "go to a place on the Web" and "get something done" or "start working on something" or "see if that work is completed" and so forth. those of us who work to design and implement applications on the Web spend a good deal of our time translating stuff that happens over time into something that can be expressed in 'resources' that 'client applications' can manipulate in order to achieve the desired results.

the technologies and techniques for this kind of work are very familiar to most of us. HTTP, HTML, and Javascript are at the "front lines" of this tech stack. IIS, Apache Server, ngnix and others are the server-side engines of this work and they, in turn rely on complied components and services that store, manipulate, and calculate data that passes up and down this stack. that is programming for the Web.

what is it about?

there is another view of the Web, too. one that focuses on what the Web "is about" -- what those 'resources' mean and what they can be used for. this is a kind of 'meta Web' that works to describe the very Web we all use when we want to get things done.

this meta Web allows people to ask questions such as "Hey, that movie that's playing at the local theater is about the Crimean War. Are there other sources on that subject I can access on the Web?" or "I just saw that my online order for canned herring is being shipped this week. Where can I go to find out more about the company that processed those pickled herring?" and so forth. the meta Web allows us to link things together in new ways - ways the original authors of some Web content didn't intend when they created their content. the meta Web makes that possible even without requiring co-ordination from these various content authors.

the technologies for creating and maintaining this meta data has been around almost as long as the tech stack for creating the data in the first place. the RDF family of formats ( RDF-XML, RDFa, turtle, etc.) are on the front lines of the meta Web. these are formats that are designed to make it easy to make 'assertions' about other resources on the Web; assertions that can even support a level of reasoning across the Web. there is a long history of formats and services built around this ability to describe what all the Web data "is about"

chocolate and peanut butter?

what has been interesting to me is that i'm seeing a blending of these two worlds (representing vs describing) in new (and sometimes confusing) ways. The JSON-LD and the Linked Data community have their roots firmly planted in the "describing" world. recently, however, i'm seeing evidence of using this "describing" tech to build solutions for the "representing" world. a recent example of this is the Hydra project. here is an attempt to combine the RDF-style data description with the state-driven feature of hypermedia. this is a very interesting project.

oil and water?

but this mixing of the two worlds is not without problems. one case that comes to mind is Drupal's foray into the hypermedia space. last year, they decided to add support for JSON-LD. however, after several months of sprints, the group decided to switch to supporting HAL - a message design rooted in the 'representing' world.

of course, one case does not make a trend. but i suspect more of these cases will crop up over the near term as people work to make their applications and services more fully "Of the Web." stepping into this space w/o full understanding of these two different worlds is likely to cause some pain, frustrate implementations, and bust schedules.

this stuff matters

so, what's that point in all this?

the differences between models designed to represent vs. models designed to describe matter.

as Leonard and i work through the new crop of media type designs and implementation patterns for the Web we're seeing both of these approaches on display. sometimes the model and the use case are in close alignment and sometimes there are notable mismatches between the technology and the intent of the implementors - and that's gonna hurt.

A New Book Project Ahead

Fri, 21 Dec 2012 10:33:00 GMT

It's been just over a year since O’Reilly released my Building Hypermedia APIs with HTML5 and Node and more than two years since I first started work on the early drafts. Inspired by the important 2007 book RESTful Web Services" by Leonard Richardson and Sam Ruby, I wanted to produce something that would - like the Richardson/Ruby book - offer a clear mode of evaluation, establish shared understanding, and promote a meaningful dialog about designing and implementing solutions on the Web. I'd hoped for some level of success and expected a healthy amount of skepticism. What I didn't foresee was the encouragement and support I received from Leonard as he read my early drafts. He offered great advice on improving the book and, even though I wasn't able to implement all his suggestions, I know the book benefited greatly from his attention. As I did, too.

Now, I have the even greater privilege of working with Leonard and Sam on a new book - "RESTful Web APIs". It’s scheduled for completion by the end of Q1 2013 and should be available soon after. The preliminary discussions and early drafts are exciting and I am hard-pressed to keep up with the already rapid pace of development on the book.

Leonard has written an extensive post on both the background behind this new book and the current state of affairs vis-a-vis APIs, hypermedia, and the Web. I’ll leave that discussion in his capable hands. What I will say here is that this new book is not just a "2nd Edition" of Leonard and Sam’s "RESTful Web Services"; It's more of a "follow-up" seven years on. It will contain the same chronicling of the current challenges facing Web developers and architects as well as a collection of up-to-date guidance on designing and building solutions for the today’s Web.

I'm really looking forward to the work ahead and to feedback from those reading our early drafts and helping us test our code and our ideas. It’s going to be quite a project!

Three Levels of Hypermedia Messages

Sat, 15 Dec 2012 14:46:00 GMT

As interest in hypermedia-oriented implementations for the Web increases, I am getting more questions about a "proper" way to design and execute hypermedia designs. Along the way, I've developed a rather simple way to describe the contents of hypermedia messages and how to "think about message design" when creating an implementation for the Web.

It all boils down to three levels of information that all exist within the shared messages on the Web: Structure Semantics, Protocol Semantics, and Application Semantics. The good new is, all three of these are needed for any successful communication between client and server - no matter the implementation style. The bad news is, most of the time these levels are obscured or muddled at implementation time. For that reason many of us do not get the chance to think about them clearly. Hopefully this blog post will help in that department and spark some comment and additional thinking on the subject.

Structure Semantics

The first level is the Structure Semantics. This is the set of rules regarding how to create a well-formed message. XML has rather simple structure semantics. JSON's rules for well-formedness are a bit more vague but reachable since JSON.parse(...) turns out to be the ultimate arbiter of such things. Determining well-formedness of other, more complex media types (HTML, Atom, HAL, Collection+JSON) is tougher, but do-able even if external validators are not always available.

It turns out to be very difficult to build a successful Web implementation that does not contain structure semantics - and that's a good thing.

Protocol Semantics

The second level is the Protocol Semantics. This is the set of rules regarding how to fashion valid requests and responses using one or more message protocols. HTTP, FTP, WebSockets, etc. are all message protocols. Most implementations for the Web use human-readable documentation to describe these semantics. For example, typical RPC-style implementations document URIs, associated request rules (HTTP methods and headers), and any possible body content. Hypermedia-style implementations express the protocol semantics directly in the message (usually in the body, but sometimes in HTTP headers). The most common way this is done is to include rules for links and 'forms' that may appear in server responses (think HTML).

Registered media types don't often include hypermedia controls. For example, CSV, XML, and JSON have no definitions for hypermedia expression within the message. However some media types such as HTML, Atom, HAL, Collection+JSON (and others), do include the predefined ability to express protocol-level information within the message sent from the server.

Application Semantics

The third level is the Application Semantics. This is the set of rules that govern the way in which application-specific information is shared between client and server. This includes names of domain data elements (users, customers, products, etc.) and specific actions within the domain (adding a user, calculating tax on purchases, etc.). Well-formed requests and responses are ones that contain valid expressions of these domain-specific concepts. There are very few registered media-type designs that contain this level of specificity and the ones that do contain it are usually are aimed at an industry-wide domain (e.g. VoiceXML and Maze+XML).

There are some machine-readable examples of application semantics that can be used in conjunction with existing structurally semantic forms (XML, JSON, etc.). XSD, JSON-Schema and other schema-based document types do a good job of expressing application-specific information. There are other example such as WSDL for SOAP and it's cousin WADL.

Most of the application-level semantics exist as stand-alone content with no standardized way to apply that information to a message. Some media type designs are better than others at supporting application-level semantics. HTML, for example, as several attributes (id, name, class, rel) with which you can apply application-level semantic information to a message.

Design Hallmarks

When designing a message format, you will always need to solve for all three levels (structure, protocol, and application). The simplest approach is to select an existing structural format (XML, JSON, etc.) and then use human-readable documentation to apply the other two (protocol and application). Doing this puts an added implementation coordination between client and server, but is quite common.

Selecting (or designing) media types that include protocol semantics and/or support applying application semantics directly within the message puts added responsibility on the message designer(s) and standardizes much more of the way client and servers interact. This can increase the likelihood that compatible implementations can be done at a distance (both in space and time) and that implementors (client and server developers) have an opportunity to safely evolve communications over time including adding new interactions to the domain-space without the need for prior coordination with the initial message designer.. It is these two aspects of the Web (support for distance and evolvability) that are a hallmark of hypermedia-style designs.

our first API Academy video shorts

Fri, 16 Nov 2012 17:30:00 GMT

i'm happy to annnounce the release of the first "API Academy" video shorts. i've been working with my colleague, Ronnie Mitra, to create a series of short (5 min) informative videos on topics related to the Web, APIs, and solution design/implementation.

looking for feedback

these first few vids are just the start. over the coming weeks and months we plan on doing more of these shorts on a wide range of topics. and we need your help. please check out these first vids and send us your feedback. You can comment here, on the YouTube site, or email me directly. we're looking for feedback on the format, on suggested topics, and even on how we could improve on this model (hosting a separate site, adding interaction, badges, etc.).

thanks for your help

any time you can spend on these and sending comments will be most appreciated. out aim is to do something helpful, engaging, and - above all - enjoyable. thanks for your help and let's see what this can become!

RESTful or not? Here comes trouble!

Mon, 03 Sep 2012 01:46:00 GMT

I've held onto this blog post for a long time. I really don't like writing this one as it opens an entirely new avenue of study/debate the time for which I do not have right now. But, as there seems to be a new round of "Is your API RESTful" talk going around, I find I've had to cover material here too many times; I'm tired of repeating myself. So, here goes.

Very often (very often) I am asked to tell someone if their implementation is "RESTful", "is a REST API", is "RESTful enough", etc. Rarely am I asked to tell someone if their chosen architectural style is appropriate for the problem at hand. IOW, people want to know if the work fits a label invented over a decade ago by a PhD candidate in his dissertation.

Almost everytime the answer is the same: "NO."

This answer makes some people sad. Some angry. Occasionally, some people ask questions about why I gave the answer I did. Rarely, do people ask me if the implementation is appropriate for the intended use.

So Let's Assume you Really Want to Know the Answer

I know there is a group of folks who just don't want to talk about this idea of actually analyzing and designing network-based architectural styles. They prefer instead to write good code, release it, and support it. That's great. I love that. I also know that some folks write dissertations about this stuff, apply this type of thinking in their daily work, and find value in contemplating the abstractions we each employ every day. I love that, too.

If you don't like to talk about analysis and design of network-based architectural styles then you can skip the remainder of this post.

Is This Appropriate?

The following exercise does not make any judgment about whether the style employed is *appropriate* for the task at hand. IOW, it's is possible that an accurate implementation of Fielding's style is *not* what is needed for the task at hand (i.e. the architect picked the wrong style for the job). If you want to judge whether the style is appropriate for the task, that is a completely different process. Fielding lays out his approach for defining a style that matches the problem space in Chapter 4 of his dissertation.

If what you want to do is make a judgment about whether the target implementation is *appropriate* for the task at hand then you can skip the remainder of this post.

Does this Implementation Exhibit Fielding's REST Style?

If you want to make a judgment on how much an implementation adheres Fielding's REST style, you need to use his measure. Fielding identified just how this style of his should be defined and what criteria should be used when evaluating this style.

If you plan on using some criteria other than that which Fielding used when inventing the named style (REST) then you can skip the remainder of this post.

A Set of Constraints

Fielding states " ...an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference". He then lays out his set of chosen constraints for a style he names " REST". It's important to decide if you accept this assertion.

If you think an architectural style is something other (or more) than "a set of architectural constraints" then you can skip the remainder of this post.

Have your Definitions Settled First

Fielding's dissertation does a good job of describing the top six (primary) constraints ( Client-Server, Stateless, Cache, Uniform Interface, Layered System, Code-On-Demand). It is usually easy to find shared understanding of these constraints. The four sub-constraints Identified as the "four interface constraints" (identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state) are only partially identified in the text. Resource Identifiers and Representations are well-defined, but the remaining two ("Self-Descriptive Messages", and "Hypermedia....") are not easily found in the original text.

Fielding added what is generally accepted as a sufficient definition of the Hypermedia constraint in his 2008 blog post " REST APIs must be hypertext driven". I have yet to find a definitive definition for the "Self-Descriptive Messages" constraint. However, the following quote from the dissertation is most often used as the definition : "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." This needs work as the word "standard" here is insufficiently defined.

Before attempting to determine if some implementation exhibits Fielding's REST style, be sure you have clear definitions for all ten constraints. Failure to have this will doom your efforts.

If you don't yet have your definitions clear then you can skip the remainder of this post.

Are You Ready?

If you agree that:

This work is *not* about deciding if an arch style is appropriate for the task at hand
Fielding's criteria are the only ones to use for this evaluation
The criteria to use is a set of constraints
You have wide agreement on the definition of all ten of Fielding's constraints

Then you are ready to begin.

Show Me All Ten

All that remains is to identify each of Fielding's ten constraints (six primary, four secondary) within the target architectural design. IOW, show where each of his ten constraints are adhered to in the implementation. If the implementation does not exhibit all ten (well nine, since Code On Demand is an optional constraint) then the implementation does not exhibit Fielding's REST style, but it *does* exhibit some other (likely un-named) style.

And Here Comes Trouble

This last step is not all that difficult. It is the previous step (agreeing on defintions) that, to this day, remains ellusive. Too many people carry around (and pontificate upon) mistaken definitions of Fielding's REST style. Those who do this not only embarass themselves and mislead others, they hamper the efforts of those trying to get to the end of this single line of reasoning.

In the end this is not a very big deal. We ask these types of questions quite often in life. Is this building in the Gothic style? Is this a pointillistic painting? Is this chair Swedish modern? What are the criteria for deciding these things? Can I just make my own up? Can I even tell the difference between medieval and modern art?

Is your app RESTful?

Standards, APIs, and the Lessons of the WAC

Tue, 31 Jul 2012 10:17:00 GMT

Warning: Those who read my blog often will recognize the following material as a real "rant." I've been watching a handful of related items slip off the rails recently and its been bugging me. I need to get this out there, so... strap in.

GigaOM ran one piece today and another last week, both of which opine on the demise of the Wholesale Application Community (WAC) after little more than two years on the scene. Both writers complain that something like the WAC effort is needed and both writers suggest, given the nature of the industry and the players involved, it's not likely to happen. However, what they fail to notice is that, while in this case the telco carriers are faced w/ a common problem, the attempted solution was way off the mark.

"The Wholesale Application Community (WAC) will go down in mobile history as one of the most ambitious, but failed, attempts at collaboration by our dear telco friends."

- Rip Gerber, Locaid

"What happens when you get four-dozen carriers in a single room? Apparently nothing. The organization tasked with creating common carrier APIs, the Wholesale Application Community, revealed on Tuesday it is dissolving, selling off its technology to Apigee and folding its development efforts into the GSM Association."

- Kevin Fitchard, GigaOm

Its not the effort that fell flat, it is the very prescription itself which did them in. And they're not alone, either. I see more of this kind of failure on the near horizon unless folks change their POV and face some fundamental truths about distributed networks.

Standardize Messages, not APIs

The key failure in the case of WAC was an attempt to standardize the wrong thing: the programming interface. This is a common problem and one that is, apparently difficult to learn since I've seen it before. For example, GigaOm readers may recall another example of industry-level standards going astray summarized in the "Cloudstack-Openstack Dustup" piece from April of 2012. I suspect several readers can call to mind similar train wrecks in the not too distant past. They usually share a common theme: disagreement on the details of the API.

All too often well-intentioned, intelligent committee members work diligently and doggedly to identify the problem and then mistakenly apply the wrong solution. While it's true (especially with regards to industry-level standards) that the problem can be defined by reviewing the data and actions taken by various players, it's a serious mistake to attempt to corral all the players into agreeing on the same set of data points and actions for all members. This almost always ends up in one of two ways: 1) a generic standard so hobbled that no member wants to use it; or 2) no standard at all since all members cannot agree on a generic standard to endorse.

The solution is right at hand, but few see it. The right way to go is to standardize the way messages are designed and shared, not the data points and actions themselves. In other words, the key to successful shared standardization is through media-types and protocols. This is especially true for any communication over HTTP, but it also holds true for standards operating at a lower level (i.e. TCP/IP).

To borrow a well-worn phrase: "The medium is the message."

The Success of VoiceXML

We don't need to look too far to see an example of an industry-led standardization success. VoiceXML was started by AT&T, IBM, Lucent, and Motorola as a way to standardize interactive voice system communications. Not long after defining the first markup in 1999 (it took only a matter of months), the standard was turned over to the W3C for continued growth and refinement.

The goals of VoiceXML were strikingly similar in nature to the WAC and Cloudstack/Openstack efforts: defining an interoperable standard that can be used across an industry group. The difference in the case of VoiceXML is that the VoiceXML committee focused on message design and domain-specific details shared by all players. They did not attempt to document all the data elements, function calls, and workflows to be used in lockstep by everyone.

This is standardizing the manner in which parties communicate, not the actual information they send back and forth. This is standardization that not only works, but can be agreed upon without jeopardizing market efficiency or industry position.

The Future is Ours

If past is prologue, the WAC melt-down is not the last one we'll see. In fact, in the last few weeks I've had the opportunity to scan two efforts, each from substantial industry sectors, where the same mistake has been made; attempts to standardize the actual API calls themselves instead of the message design used to communicate between parties. I can predict with a high degree of certainty that the work will either be abandoned before it is ever put into place or languish mostly unused due to it's ineffective generic design.

This is not the inevitable result of competing interests in the global marketplace. This is the doings of well-meaning people aiming at the wrong target, using inappropriate solutions for real problems. We can do better. We can learn from successful interface designs from both industry and open standards (i.e. HTML, Atom, VoiceXML, and others). We can focus on making it possible to consistently communicate a wide range of information freely between parties instead of attempting to narrowly constrain systems to a single set of possible interactions.

The future of an effective Web, a growing and vibrant distributed network, rests in the hands of those who would take on the task of writing the vital standards which make it work. I, for one, am not looking forward to seeing the same mistakes repeated over and over again. On the other hand, I am optimistic that there are enough dedicated and talented individuals, ones committed to the future of open communications, ready to join standards committees, ready to ask hard questions, ready to teach and to learn, and ready to meet the challenges that lie ahead.

The future is ours.

Programming in the Cloud

Sun, 29 Jul 2012 21:12:00 GMT

Authors note:
On August 3rd I will be presenting a talk ("Programming with the OSS 'Cloud Stack'") at CloudDevelop in Columbus, OH. What follows is a preview of what I'll be covering in that talk.

While quite a bit has been written about how "the Cloud" is altering the landscape for platforms (PaaS) and software (SaaS) providers, even infrastructure (IaaS) offerings, not much has been written about how all this affects programmers themselves. What does the Cloud mean to those working to architect, design, implement, and maintain code that runs on these various Cloud offerings? Do the possibilities of remote, commoditized hardware and software alter the way developers and architects execute their work? does it call for new tools? new skills? Does this all result in the need for a new working environment? My All Cloud Diet

These are some of the questions I set out to explore when I recently put myself on an "All Cloud Diet" for six months. During this "diet" I used only a Google Chromebook and/or an Android smartphone to do all my work. I still needed to do the things any active developer/architect is expected to do including coding, debugging, testing, collaborating with colleagues, etc. I also needed to be able to manage source control services, provide code reviews and comments, deal with bug reporting, manipulate and publish structured data, and deploy the final results to production servers. All from a device that has no appreciable hard-drive space and does not allow installing any customer software. In essence, I was on a strict diet of browser-based and plug-in based tools and services reachable via Internet connection.

Discovering a New Toolset

Although it took a while to get comfortable in my new environment, I found that there are quite a number of very powerful tools and services available that support the full life-cycle of a typical developer/architect today; especially one focused on building solutions for the Web.

In relatively short order I was able to find full-featured browser-based editors (even ones that support line-by-line server-side debugging!), tools for managing data stores (CouchDB, MongoDB, etc.), used github as my code repository (including collaboration & code review options), was able to post test scripts for execution and review, and even deploy my projects to a wide range of server providers all from my browser.

Along the way I discovered I had an easier time collaborating online with colleagues in other locations, was better able to take advantage of the most recent releases of new services & tools (since there was no "install" or "update" I had to manage), and was more mobile in the process. In fact, among the new tools I discovered were my own personal growth as a developer.

Compelling Advantages

While going through this experiment, I also got a chance to interview some of the people providing these "Cloud" tools and services. Along the way I learned that there are some additional compelling advantages to this new environment.

For many startups, there is a desire to reduce initial costs and reduce barriers to collaboration. By focusing on cloud-based tools and services, new companies can ramp up quickly and often can create accounts on many free services to begin. SMBs (Small to Medium-sized Businesses) can use Cloud tools to add agility and flexibility to their organizations. If a new contract calls for added staffing, using Cloud-based services means reduced installation costs and makes remote collaboration easier.

Going "All Cloud" also means that production services can be monitored, even modified from almost any location using simple browsers. This “anytime/anywhere” option can improve response time when it is critical without requiring special hardware or software at either the client or server end.

Goodbye Desktop, Hello Tablet?

So, is it time to throw away our desktops, grab our tablets, and hit the road? Is the era of internal networks and dedicated servers a thing of the past? No.

While I found powerful tools and learned to take advantage of many solid Cloud-based services, much of this space is still very "bleeding edge" technology. Not all programming languages, runtime environments, and server profiles are represented “in the Cloud.” And there are still many details to work out in order to make assembling a full-featured “Cloud Tool Chain” easy, reliable, and cost effective. But I can see that it is a possibility and I have met people who are working to make that possibility a reality.

My advice is for everyone to conduct their own experiments; try out their own "Cloud diet" and see what you learn. Even if you decide that not all the pieces you need are available today, you may still discover there are ways to leverage cloud-based tooling to reduce barriers, add flexibility, and increase productivity in various aspects of your development efforts.

join me for Tech-Talk Tuesday

Thu, 21 Jun 2012 11:34:00 GMT

every two weeks, Layer 7 provides an informal online meet-up called Tech-Talk Tuesdays for developers and product managers interested in all things API. as Layer 7's newly minted API Architiect, i have the pleasure to join Matt McClarty for the June 26th event.

this is not a lecture or taped presentation; it's a real-time interactive convo between Matt and myself and everyone who joins in the event.

June 26 - Designing Flexible APIs

this coming Tuesday the topic is "Designing Flexible APIs" and below are my suggested topics for the session:

Employing the USE methodology for your API (Usable, Scalable, Evolvable)
When (and when NOT) to version your HTTP API
Supporting multiple formats for your API (XML, JSON, etc.)
Designing the Message format (not the URI format) for your HTTP API
Planning for Re-usability for your HTTP API
The Power of Hypermedia as a design element for your HTTP API

hopefully, these topics pique your interest and you'll tune and join us. you can post questions, comments, suggestions for additional topics, etc. using:

Facebook
Livestream
Tweet w/ the hash tag #layer7live
Email techtalk7@layer7.com

NOTE
the session will be recorded so, even if you can't make it, you can send in your questions/comments ahead of time and check the playback once it's posted.

i'm looking forward to a lively convo and a chance to meet you next Tuesday.

Mike Amundsen, Principal API Architect for Layer 7

Mon, 18 Jun 2012 09:58:00 GMT

it's my honor to announce that, as of today, i am part of the Layer 7 team as Principal API Architect.

Layer 7 is a leading provider of security and management products for API-driven integrations spanning the extended hybrid enterprise. in my role as Principal API Architect, i'll be involved with Layer 7's Business Services group helping customers harness the power of Web APIs for their business. that means i'll be working as both a customer- and developer community-facing technical expert advising business leaders, developers and architects on how to design, develop and deploy world-class Web APIs.

joining Layer 7 also means i will be able to continue to pursue my personal mission:

Improving the quality and usability of information on the Web.

as regular readers of my blog know, i've spent the last several years exploring and experimenting with Web APIs and the technical and design details used to create and maintain them. over that time, i've had the pleasure to work with several organizations to help them build APIs that are usable, scalable, and evolvable. the opportunity to combine my experience with that of Layer 7 is very exciting and i'm looking forward to the challenges ahead.

this week i'll be talking about some of my past experience as well as the possibilities for the future in my QCon New York talk The Costs and Benefits Of Buliding Hypermedia APIs with Node.js. i hope you'll join me at QCon and stop by the Layer 7 table at the event.

moving forward, there are lots of great opportunities to learn and grow and i hope you'll join me in my mission.