DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DataOps
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • Techstrong.tv Podcast
    • Techstrong.tv - Twitch
    • DevOps Unbound
  • Webinars
    • Upcoming
    • Calendar View
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • Calendar View
    • On-Demand Events
  • Sponsored Content
  • Related Sites
    • Techstrong Group
    • Cloud Native Now
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Techstrong TV
    • Techstrong.tv Podcast
    • Techstrong.tv - Twitch
  • Media Kit
  • About
  • Sponsor
  • AI
  • Cloud
  • CI/CD
  • Continuous Testing
  • DataOps
  • DevSecOps
  • DevOps Onramp
  • Platform Engineering
  • Sustainability
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps
    • ROELBOB
Hot Topics
  • There’s No Value in Observability Bloat. Let’s Focus on the Essentials
  • Observability Leaders: The Mighty Minority Holding Their Own Against Outages
  • Cisco Acquires Splunk to Create Observability Powerhouse
  • Nobl9 Unfurls Reliability Center for Managing SLOs
  • Harness Launches Open Source Gitness Platform

Blogs Languages and DevOps: API-First

Languages and DevOps: API-First

Avatar photoBy: Don Macvittie on March 18, 2021 Leave a Comment

One of the places development has made significant changes is in the land of APIs. These days, a program almost isn’t considered a proper application unless it offers APIs to do most of what can be done via UI (and even command line). This is a big deal for several reasons; first and foremost, the ability to subdivide the work and then test each subdivision. A proper API does one thing and does it well. Testing can validate that this statement is true for any given API. It also allows for distribution of processing. It is far easier to use a load balancer to scale APIs than it is to scale a monolithic application. And finally, it helps with portability, because with API-first, developer users don’t care what platform it’s running on, just that it can be reached via URL and responds as expected.

Everything is a trade-off, and there are several places that API-first has issues. Integration testing is objectively harder. Loosely coupled applications, in general, are harder to test, and requiring multiple portions of an application be available to run testing becomes onerous, particularly as the layers of APIs start to build up. Second, security is another issue – particularly if you’re offering a public-facing API, but also for internal usage. Once an attacker has access to the network, internal-only APIs are no different to them than external. Smart IT departments design internal APIs with the same controls that external requires. Third is DevOps in general. API-first grew up in the agile/DevOps world, but because there are cascading dependencies, is actually harder to manage DevOps for than most monolithic applications. Finally, documentation – the bane of API-first’s existence. The number of poorly documented APIs vastly outnumbers the astoundingly well-documented ones. Even well-documented APIs, like Google Places, require some thought and testing to use well. Poorly documented ones – my favorite is, “It’s mysite.com/users – everyone knows what’s in there!” – are next to useless without a learning curve.

With all of that said, what about languages? That greatly depends on what you’re doing. Users don’t care what language it is implemented in – as noted above, they care that the API can be reached via URI, and that it behaves as expected. So you do have options. Indeed, at this point in the evolution of APIs, the language options are so open that you’ll probably be choosing an API definition language instead of a programming language, and just instruct your definition tool to spit out the language of choice.

AWS Builder Community Hub

Wait, what?

For those who haven’t followed API development closely over the last few years, it goes something like this. APIs became standardized, then APIs became a big deal, then smart people started to think in terms of code generation á la ancient 4GLs. What if you could use a specification language to describe what you want to do, then pick your language and tell the tool to generate the API? What if you could do this for the entire API hierarchy? That’s where we are. I’m most familiar with OpenAPI and RAML, but there are a large number of specifications out there, and a larger number of tools to develop in them. Before my API friends freak out, of course this is an over-simplification of what happened. I only have 1000 words, max, and my editor would like less. Relax a bit.

And then you generate.

I’ll rely on my own experience here, but there are literally dozens of tools available to get you from idea to API interface (doing the work behind the interface is where you come in). With Swagger CodeGen, the tool I’m most familiar with, you specify the API, then generate server interfaces (they call them stubs), and generate client libraries. Finally, you develop what goes on behind the interface on the server side, and (you or others) use the API on the client side. When I say “generate,” I mean “Tell it your favorite language, and click generate.” It spits out the code you can then use to flesh out your API. It does not spit out the info to get the API into your DevOps toolchain, so you’ll have to do the work for that. Which means the more APIs you can generate in a batch, the less DevOps lifting you’ll have to do (more on that if/when we cover microservices). Since most languages can easily be placed into DevOps via their build tools, I don’t want to make this sound too onerous – security and testing will be a bigger problem, by far.

API security is slowly getting automated and placed right into generated code, but all the usual bits, like certificate management, still have to be handled. The interesting thing, that hasn’t (yet) gotten a ton of attention, is security of clients. It is far harder to verify that the client library is secure when the purpose of that library is to grant access to your API. I expect we’ll eventually have to get there for some applications, but today, it appears to be largely individual orgs figuring out how best to lock down client libraries, and most of the limiting factors end up server-side.

I’ve generated Python, Java and Ruby APIs via various toolsets, and considering the problem domain is still relatively small, they work fine. And it saves one piece of the puzzle … but does introduce another piece – coordinating client and server updates via DevOps.

Keep making the apps that run the world, and use API generators to further standardization, spitting out whatever language you need on the backend, and a portable interface for clients.

You. Rock.

Whatever your language of choice, in the end, it will likely be your build tool that links it to DevOps. Your biggest concern for DevOps will probably be portability, at least in the near future. Meanwhile, keep rocking it. You’re doing the work that needs doing, even if it isn’t the part of DevOps everyone is currently buzzing about.

Recent Posts By Don Macvittie
  • Generative AI: The 90% Rule
  • Unused Code: Proving a Negative
  • Steady On. We Still Have a Job to Do
Avatar photo More from Don Macvittie
Related Posts
  • Languages and DevOps: API-First
  • Apply DevOps automation to APIs with Akana
  • How Google’s Acquisition of Apigee Impacts Developers
    Related Categories
  • Blogs
  • DevOps Practice
    Related Topics
  • API
  • API First
  • distributed applications
  • Swagger
Show more
Show less

Filed Under: Blogs, DevOps Practice Tagged With: API, API First, distributed applications, Swagger

« PagerDuty to Offer European Data Hosting
Immersive Labs Chooses Global Channel-First Strategy With 50 New Partners And Transparent Structure »

Techstrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Neo Quiz

Upcoming Webinars

Infosys Zero Cost Mainframe Transformations
Monday, September 25, 2023 - 11:00 am EDT
How PRINCE2 Improves Cybersecurity
Tuesday, September 26, 2023 - 11:00 am EDT
AWS and Sumo Logic: Observability With OpenTelemetry
Tuesday, September 26, 2023 - 1:00 pm EDT

GET THE TOP STORIES OF THE WEEK

Sponsored Content

JFrog’s swampUP 2023: Ready for Next 

September 1, 2023 | Natan Solomon

DevOps World: Time to Bring the Community Together Again

August 8, 2023 | Saskia Sawyerr

PlatformCon 2023: This Year’s Hottest Platform Engineering Event

May 30, 2023 | Karolina Junčytė

The Google Cloud DevOps Awards: Apply Now!

January 10, 2023 | Brenna Washington

Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

December 9, 2022 | Mike Vizard

Latest from DevOps.com

There’s No Value in Observability Bloat. Let’s Focus on the Essentials
September 22, 2023 | Tomer Levy
Observability Leaders: The Mighty Minority Holding Their Own Against Outages
September 22, 2023 | Jeff Stewart
Cisco Acquires Splunk to Create Observability Powerhouse
September 21, 2023 | Mike Vizard
Nobl9 Unfurls Reliability Center for Managing SLOs
September 21, 2023 | Mike Vizard
Harness Launches Open Source Gitness Platform
September 21, 2023 | Mike Vizard

TSTV Podcast

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays

Most Read on DevOps.com

Should You Measure Developer Productivity?
September 18, 2023 | Bill Doerrfeld
JFrog swampUP: Addressing the Advent of AI
September 18, 2023 | William Willis
Buildkite Acquires Packagecloud to Streamline DevOps Workflows
September 19, 2023 | Mike Vizard
What DevOps Teams Should Know About Phishing and the Supply Chain
September 19, 2023 | Gilad David Maayan
Oracle Previews Latest Java 21 Innovations
September 19, 2023 | Mike Vizard
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2023 ·Techstrong Group, Inc.All rights reserved.