Join Two ProgrammableWeb Talks: Building Developer Community and What's Beyond REST

On April 20th, I'll be hosting two conference sessions at MuleSoft's upcoming Connect conference in San Francisco. The first of these is a session on What's Beyond the REST Architectural Style for APIs and the second is on the do's and dont's of building developer communities. (Disclosure: MuleSoft is the parent company to ProgrammableWeb). 

ProgrammableWeb strives to maintain an independent and objective voice within the API economy and each year, I get asked to bring some of that neutral perspective to MuleSoft's Connect in the form of sessions where I'm either presenting or leading an industry panel. Much the same as last year (see the embedded video below), this year, I'll be doing both. But if you're an API provider or you're contemplating the start of your API journey for the many reasons that others are diving in -- extending market reach, business transformation, microservices, the Internet of Things, and so on -- my two sessions are not the only reason to attend.  The entire conference is a great opporutunity to rub shoulders with some expert practitioners on the subject matter. One reason is that you'll get to hear about some real enterprises that are doing it now.  You'll hear about what motivated them to start their journeys, how they defined success, and how they tackled the risks, scale, and cultural challenges of an API way of thinking. Check the enterprise-grade list of speakers and you'll see what I mean.

In terms of the sessions I'm leading, here's the low-down.

Last Fall, I was invited to be the keynote speaker at Capital One's internal developer conference called NEXTECH. Yes, forward-thinking enterprises that are serious about APIs are known to run internal developer conferences because that's one way you change the entire company's culture -- to help all personnel understand that moving to a services-driven application network and initiating ideas with an API-led way of thinking can change a slow-turning battleship into a nimble speed boat that can React to market changes and turn on the dime. While at that conference, I had a chance to meet with Capital One's very talented architects who were lamenting the shortcomings of the REST architectural style for certain use cases.  Loathe to turn the clocks back to the days of SOAP and XML, there remained the burning question of what to do about it. This is no doubt a familiar conversation for those of you whose enterprises are on the verge of API sprawl. 

As great as REST is, it just ain't the end-all be-all. 

I first fell in love with APIs back in 1992 when companies like Microsoft, Lotus, and Novell were Decoupling messaging and email clients from the underlying infrastructures that drove their features. Microsoft had MAPI, Lotus had VIM, and Novell had its Message Handling Service and all three companies were looking to drive innovation by enabling third-parties to build new and interesing applications for their messaging systems. The more I studied their API architectures and capabilities, the more I embroiled myself in the long term march of Integration technologies. Now, 25 years later, I think I can safely say that every time a new one comes along -- everything from the original UNIX remote procedure calls to Network Dynamic Data Exchange (Network DDE) to Electronic Data Interchange (EDI) to Extract, Transform & Load (ETL) to Common Object Request Broker (CORBA) to XML- RPC (the predecessor to SOAP-based Web services to REST -- I hear the same basic refrain; "utopia has been achieved."  

Really? So, what about the last time utopia was achieved? I guess it wasn't so perfect after all.  And so, the march continues.  Just when you thought REST was great, along comes GraphQL from Facebook. And GRPC from Google. 

Trust me on this one folks; this march is far from over. And that's why I wanted to run a session on what's beyond REST. Because 25 years from now, relatively speaking, REST could be a fly on a rhino in a wading pool in Africa. Who knows? 

To help me figure that out, I've brought in some experts on the matter. Capital One's senior director of web strategy Andrew Csontos (yes, the guy who originally stirred the pot) will be joining us. Then, there's Google's Tim Burks. I like to keep in mind how Google basically started this entire API economy thing when it launched Google Maps API back in 2005. What Google does, others take notice and soon after, they are not usually far behind. Well, now, Google is on a path to make it's 150 or so existing public APIs available as gRPC APIs too. If history is any indicator, there will be followers. Burks will be on-hand to explain why Google was compelled to push beyond REST.  

Then, there's this small outfit called the Apache Foundation that produces a whole bunch of great API-related open source technology. One of those technologies is the little-known AVRO and to talk about that, we've got Matt Sicker who is both a senior consulting with SPR Consulting and a member of the Apache Logging Project Management Committee. Sicker is an expert on Big Data technologies, the Industrial Internet of Things (for which REST is not always the answer), and Apache Kafka. So, he will no doubt bring some very interesting perspective to the panel. One question I'm hoping to get answers to from each of our panelists is what to do if you want a stateful API, but you don't want to rewind the clocks to SOAP and XML. When I made a Facebook post about the session, 

Finally, later in the day, I'll be giving a presentation on building developer community. This is a subject that is routinely covered as a part of of the prescriptive advance you'll find in ProgrammableWeb's API University and I'll be sharing some of the best advice from those articles and contributions. For example, Twilio just shared its Top 3 Tips For Building APIs So Developers Actually Use Them on ProgrammableWeb.

If you're interested in attending these or other sessions at the event, I've arranged for a 50 percent discount for ProgrammableWeb's readers. As you go through the event registration process, be sure to supply the code PW-50-CONNECT when the opportunity arises. 

Here's the video from last year's panel discussion and hope to see you there!

Be sure to read the next API Management article: MuleSoft Anypoint "Crowd" Focuses On Promotion, Discovery, and Re-Use of Developer Assets