How to Turn Last-Minute API Crises into Team Cohesion: A Step-by-Step Guide

A few days ago, a member of the middle‑platform team rushed to the author on the final day before production, reporting a serious issue that could jeopardize business rollout. Tensions rose as the upstream caller blamed the middle‑platform for incomplete interface design, while the middle‑platform team accused the project side of submitting unsatisfactory requirements, resulting in a blame‑shifting deadlock.

After mediating the conflict and resolving the immediate problem, the author realized the need for stronger governance of the middle‑platform services to prevent similar incidents as usage expands.

1

Step‑by‑Step Guided Process

Step 1 – Empathic Praise to Build Team Cohesion

Following the project wrap‑up, the author invited the developer to a small meeting room, observed his nervous yet aggrieved expression, and began by praising his performance: "You communicated very well, bravely voiced your team’s perspective, and presented convincing reasons." The developer was surprised, and the praise helped dissolve his resistance, turning the moment into an opportunity to reinforce team unity.

Step 2 – Brainstorming a Joint Process to Solve Recurring Issues

Once emotions settled, the author led a brainstorming session that produced a concrete mechanism: an "Interface Delivery Review" before development. This review ensures that newly designed APIs meet business scenario requirements before integration testing or production, preventing late‑stage defects.

The review involves a technical alignment between the middle‑platform team and the project team to verify that the interface satisfies all conditions before coding begins, acting as a gatekeeper for the many downstream projects that rely on the middle‑platform.

Step 3 – Self‑Reflection and Design Capability Enhancement

With resistance gone, the author highlighted design shortcomings that were not captured in the requirement documents. The developer acknowledged his own design flaws and committed to learning from the experience, reinforcing the importance of robust design practices.

The author concluded the case but raised a further question: beyond generic API design guidelines, what special considerations should middle‑platform teams keep in mind?

2

Key Focus Areas for Middle‑Platform Services

While general API design principles are well covered in Zhu Yun’s article "What Every Engineer Should Know About API Design and Implementation," the author emphasizes three additional concerns for middle‑platform development:

Over‑Privileged Access

Because the middle‑platform serves multiple callers, data security is critical. Query interfaces must enforce the strictest business conditions to prevent cross‑domain data leakage.

Transaction Idempotency

Idempotency is essential for all interfaces, especially when the middle‑platform itself calls other services. Ensuring idempotent operations avoids duplicate effects in complex call chains.

Principle of Least Knowledge

When exposing services, the API signature should adhere to the least knowledge principle, preventing callers from misusing the interface and causing unpredictable outcomes.

The author also recommends the book "The Art of Software Framework Design" for developers who wish to deepen their understanding of API design.