DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. Common API Mistakes

Common API Mistakes

A lot about API design and management can trip you up. Keeping these points in mind will help you take a design-first approach and avoid the most common mistakes.

Ali Salman Rizvi user avatar by
Ali Salman Rizvi
·
Oct. 31, 17 · Opinion
Like (4)
Save
Tweet
Share
8.92K Views

Join the DZone community and get the full member experience.

Join For Free

Do you know if you are doing it right?

This is the question that many of us are faced with when starting with APIs, and quite invariably, there would be either of two broad scenarios that we generally find ourselves in. We are either starting green field under the clear blue sky with every little thing to elicit, introspect, and design; or else we are in a continuum, trying to understand the current system, and slice and dice what is otherwise called a monolith into smaller more manageable APIs.

I would say that in either of the two scenarios, it is important to go design-first.

Bear in mind that designing an API is all about keeping it simple, intuitive, loosely-coupled, and scalable. And this is where people are likely to make mistakes. I will list out some common mistakes that we generally make either as architects, designers, or developers. Accordingly, the order of these items has been kept in terms of the increasing level of granularity or decreasing level of impact – whichever way you want to look at it – starting from architectural concerns and then getting into the weeds.

API Anarchy

Image title

Thinking at the enterprise level, managing APIs cannot happen without appropriate governance in place. API governance takes into perspective the key aspects of managing APIs, including aspects like asset management, configuration management, change management, quality assurance, and security. A good source reference can be found here.

Ignoring DDD

Consider a scenario when API specs are written in silos and involve overlapping domain entities. It may cause redundancy of effort, confusion, and eventually maintenance hazards and rework. Imagine within a banking enterprise, if two lines of business – say retail and commercial – come up with their own version of API specs for processing payments; it will cause unnecessary redundancy at all levels.

Django Unbound

This concept of identifying bounded contexts is very much borrowed from the microservices architecture style, but bear in mind that APIs are merely one implementation of the microservices architecture style, and the end objectives of writing APIs are no different. A domain model, once defined, should give rise to an object model with bounded contexts identified, and that should serve as the foundation for defining the responsibility or boundary and request-response model of an API.

Image title

Note that definition of the domain model is where the business context plays heavily and is inculcated in the definition of an API.

Divide and Conquer

It's quite a common scenario: you are splintering a monolith one piece at a time, but without a good overall design behind it, the effort may go waste. Use of an anti-corruption layer is advised.

Modeling-Shy: the Tendency to Get Into Code and Skip Modeling YAML or RAML

It is important to go model-first and then maintain the model during the course of API implementation. Tools like Swagger (for YAML) or Mulesoft API designer (for RAML) help in getting to the details up-front. Besides early design granularity, the benefits are multiple:

  1. YAML/RAML models serve as scaffolding for the initial version of APIs that could be generated from them.

  2. They serve as a template and a means for sharing API specification documentation with the audience.

  3. They serve as a template for generating API mocks and unit test cases.

  4. They help in identifying and defining generic types that form the building blocks of the object model.

Not Enough Layers in the Cake: Missing API Strategy

Keeping the icing too thick or the cake too dense, or in other words, not identifying the layers needed for the APIs to be meaningful, reusable, and loosely-coupled, could be ominous.

Image title

Following API-led-connectivity, as recommended here, is a way to keep APIs pertinent to the respective bounded context and coupled loosely enough so as to derive a good trade-off between reuse and API ownership.

Letting REST Principles Rest in Peace

Not proactively injecting something like a correlation identifier in the logs is one common mistake that generally goes undiscovered until integration testing really commences. This is something that should be part of the underlying API framework that every API must inherit from so that consistency in transaction traceability is ensured.

We all know that Murphy’s Law is for real and there will always be a wide variety of things that could go kaput in a given implementation. However, arming yourself with the right design principles and knowhow of potential pitfalls is what could hopefully help fellow developers circumvent common API mistakes.

API

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Best Practices to Succeed at Continuous AWS Security Monitoring
  • Three SQL Keywords in QuestDB for Finding Missing Data
  • Data Mesh vs. Data Fabric: A Tale of Two New Data Paradigms
  • SAST: How Code Analysis Tools Look for Security Flaws

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: