Net API Notes for 2021/04/21 - Issue 159

It is gorgeous spring weather in the Northern Virginia area. But before I go for a walk, let's get to the latest batch of notes! We start with examining the API that sits between the front and backend code.

NOTES

WHEN IT COMES TO FRONTEND TO BACKEND COMMUNICATION, DO YOU REALLY NEED AN API?

Oliver Libutzki asks the provocative question, "Do You Really Need An API?". Oliver makes the case that creating an abstraction, like an API, doesn't come without cost. Identifying boundaries, balancing stakeholder concerns, deploying, documenting, and managing another piece of code takes time and attention. He then questions the wisdom of client-side rendering, with the subsequent division of teams and resources.

I readily agree that server-side rendering is vastly underappreciated. However, it depends. Consider a web agency, where the team's outputs are marketing websites or single-page applications (SPAs) with clear project boundaries. Oliver's argument makes much more sense for those architectural patterns than it does for a platform team creating CI/CD toolchains for thousands of developers.

No architectural pattern is 100% correct all of the time. I appreciate Oliver encouraging caution and the issues that he sees. I'd love, however, to hear more about how to identify the selection criteria to arrive at the correct conclusions.

OTHER WAYS TO USE ASYNCAPI DOCUMENTS

When talking about API specifications, whether it is OpenAPI or AsyncAPI, I can see people pigeonholing their API descriptions as documentation only. Granted, a thoughtful, complete API description goes a long way toward communicating usage essentials for integration partners. However, it is also akin to buying a car to only listen to the radio; description formats can take your development to new places if you are willing to explore.

Dale Lane shares that same sentiment in his piece, "Other Ways To Use AsyncAPI Documents". Dale links to several short videos demonstrating how he uses AsyncAPI descriptions of Kafka topics to:

• Scaffold mock events
• Visually Prototype
• Generate code

It's great to see the tooling around the AsyncAPI specification continue to mature.

APIS BEYOND TECH COMPANIES

I'll finish this edition of the notes with everyone's favorite API resource, Havard Business Review?

Believe it or not, Tiffany Xingyu Wang and Mulesoft's Matt McLarty appear in the vaunted publication with their article, "APIs Aren't Just For Tech Companies". The piece quotes Twilio's Jeff Lawson, who recently argued that software delivery must be a core competency for every business.

To help businesses that aren't stereotypically software reap the benefits of APIs, Tiffany and Matt propose three impactful patterns:

• Dismantling current value propositions to re-distribute via APIs
• Establishing an "Outside-in" mindset for service design
• Cultivating ecosystems of mutually beneficial functionality, rather than one-off projects

Many of the stories provided (the Bezos memo, Stripe disrupting the payment space, etc.) might be old-hat for some. However, it is always worthwhile to see which stories continue to resonate, especially for different audiences.

MILESTONES

• Twilio released its own OpenAPI description. It could be a great "real world" example for those tired of kicking a tool's tires with the PetShop example.
• Stoplight announced real-time project collaboration.
• Speaking of Stoplight, they recently launched a new podcast called API Intersection. I was lucky enough to appear on the first episode to discuss the importance of empathy and getting started with API governance.
• A new edition of the ThoughtWorks radar was released. Under "tools", the JSON-syntax checking "Spectral" gets a shout-out. Elsewhere, FastAPI gets some complimentary things said about its ability to generate APIs from Python type hints.
• Meanwhile, InfoQ's architectural trends report has a number of API items of note. This includes declaring the monolith/microservices debate over and the emergence of "next-generation GraphQL".

WRAPPING UP

ORACLE V. GOOGLE FOLLOW UP

In the last newsletter (erroneously labeled issue 153), I covered the Google v. Oracle API case resolution. The subsequent social-media discussion turned up a few additional points and clarifications I want to share.

I did point out that the U.S. Supreme Court sidestepped answering whether an interface could be copyrighted. Instead, they chose only to answer the specifics of the case at hand. That was if APIs were copyrightable, then Google's actions constituted fair use.

As Kin Lane alluded to on the Postman blog, that no-call on copyright at the highest level means the lower court decision stands; in other words, the Supreme Court's ruling did not invalidate the lower court's opinion that APIs are copyrightable.

(For disclosure, Kin is now my manager at Postman, and somehow his Slack messages all smell like peppermint.)

The "fair use" Google president is a positive result but not problem-free. As Harvard professor and political activist Lawrence Lessig has said, "Fair use is the right to a lawyer." Or, as Google's Tim Burks summarized, "leaving this a question of fair use leaves API developers subordinate to lawyers". A court still is required to determine whether fair use applied on a case-by-case basis.

FINAL THOUGHTS

I continue to update NetAPI.events. If you know of an upcoming API event, whether it is online or in physical space, let me know, and I'll be glad to add it.

Also, a big thank you to my Patreons. It is because of their support that the newsletter remains free of advertising and outside a paywall. It is because of these few that we all benefit.

Till next time,

Matthew @libel_vox and matthewreinbold.com