Breaking change

As explained in Building Web APIs with ASP.NET Core

A breaking change is a modification that can cause existing clients or system integrations to stop working correctly.

A breaking change modifies a web application or API in a way that can make existing client integrations or third-party consumers stop working correctly. Regression bugs, interface modifications, type mismatches, and other backward-incompatibility problems can all produce this result. section 3.3.1

API versioning can reduce the immediate impact by publishing a new version at another URI or through headers while keeping older versions available. Clients can then adopt the change when ready instead of being forced to update immediately. section 3.3.1

Treat versioning as a trade-off rather than a complete solution:

• Maintaining multiple versions increases endpoint and source-code complexity and can conflict with DRY by encouraging duplicated implementations. section 3.3.2
• Keeping old versions online can preserve endpoints with known bugs, performance problems, security flaws, or outdated standards. section 3.3.2
• Supporting old clients can pressure teams to preserve backward-compatible database schemas, business logic, DTO structures, and third-party library choices. section 3.3.2

Figure 3.9 Advice on API versioning

Consult the API versioning advice figure when weighing simultaneous versions against their operational and security costs. section 3.3.2

How Building Web APIs with ASP.NET Core covers it

How deep it goes

Defines common causes, describes parallel API versions, and evaluates complexity, security, and architectural trade-offs.

Examples

Uses regressions, interface modifications, type mismatches, vulnerable legacy endpoints, and simultaneous API versions as examples.

What it assumes

Assumes familiarity with web applications, APIs, clients, integrations, and production deployment; defines breaking changes from those foundations.

What you can do after

Evaluate whether API versioning adequately contains client disruption without creating unacceptable duplication, security exposure, or architectural constraints.

How it connects

Connects breaking changes with API versioning, regression bugs, type mismatches, backward compatibility, security flaws, and DRY.

liveBookmanning.com

Read Building Web APIs with ASP.NET Core on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Automating API DeliveryA breaking change is an API modification that can cause existing consumers or integrations to stop working.
• 

  liveBookmanning.com
  Google Anthos in ActionA breaking change is a modification to an interface or behavior that can cause existing dependent clients or services to fail.
• 

  liveBookmanning.com
  Go in Action, Second EditionA breaking change is a modification that can prevent existing consumers from continuing to work without updates.
• 

  liveBookmanning.com
  Terraform in Depth: Infrastructure as Code with Terraform and OpenTofuA breaking change is a software change that makes previously valid code, configuration, or interfaces require modification to function correctly.

Compare how 5 books explain breaking change →

Related concepts

• backward compatibilitycontrasts with · Backward compatibility is the property of a changed or newer system remaining usable by existing clients and consumers of its earlier interfaces, behavior, or data.
• versioningaddressed by · The practice of identifying and managing successive revisions of files, data, models, interfaces, or other artifacts so changes can be tracked and earlier states recovered.
• major versionproduces · A major version is the primary component of a version identifier that distinguishes a release line and commonly signals potentially backward-incompatible changes.
• review processaddressed by · A review process is a structured evaluation of work, performance, artifacts, or proposals against relevant criteria to assess quality, progress, correctness, or suitability.
• sunset strategyincludes · A sunset strategy is the planned discontinuation and shutdown of a software component, such as an API or subsystem, after its supported service period.

This explainer was generated by Manning's knowledge graph from the text of Building Web APIs with ASP.NET Core. The section links point to the parts of the book it draws on.