RFC 9745 and its impact on API governance

Michel Fortes

10/06/2025 12/06/2025 5 minutes

A Internet Engineering Task Force (IETF) – an open international organization that develops and promotes technical standards for the Internet, such as protocols TCP / IP, HTTP e DNS – has just launched the RFC 9745, that defines a standardized way of reporting the depreciation of resources in the context of HTTP, which is especially relevant for APIs based on this protocol.

In short, from now on, servers can inform their clients about the deprecation status of certain features using the response header Deprecation, whose value is a date, in the past or future, indicating that the resource has already been or will be depreciated. Additionally, it is possible to use the header link to point out documentation and also the Sunset, showing the date on which the resource will become unavailable.

In this article we will evaluate the feasibility of applying this pattern in the real world. Using best practices in the development of APIs, we will start from definition files that follow the OpenAPI Specification and we will end in API KrakenD gateway.

Impacts

As stated, this new standard is especially important for web APIs, that is, for the APIs that adhere to the protocol HTTP, like the famous ones REST. In this context, the RFC provides a means of carrying out depreciation policies — previously restricted to documentation or design team — at the time of execution.

Therefore, this new feature has the potential to seriously mitigate integration failures, allowing developers to make the necessary adaptations well in advance. In fact, it is worth remembering that we are entering the era of AI (with its agents, MCP servers, etc.), which only increases the impact of this new standard, since they can learn and adapt on their own when faced with deprecation signals.

In the context of governance, the RFC also makes it possible for suppliers to gateways de API (as Kong, Tyk, KrakenD, Traefik, APISix and etc.) consider the new standard during automated processes. deploy de APIs, especially when we think about APIOps based on OpenAPI specification. Let's see.

The specification OpenAPI provides for the indication of depreciation of operations through the field deprecated. With this new RFC, it is simply natural for us to think about link things, that is, to make the depreciation indication present in the definition files match the configuration of the gateways, which, once running, inject the new response header into the appropriate operations. This improvement would take governance to the next level of quality!

Proving the concept

We will use the definition file adhering to OpenAPI Specification (OAS) to describe our API, we will build a parsers em Go using the libopenapi, we will count on the KrakenD , the API gateway and a HttpBin , the backend.

Full project details can be found in this repository. So, I will just highlight the main points:

The definition file (openapi.yaml)

paths: (...) /users/{userId}: (...) delete: (...) deprecated: true

Note that the user delete operation relies on the default field of OAS deprecated with the value true. Well, it's easy to see that we're facing a impedance mismatch when we try to do this Boolean interact with the new headers provided in RFC 9745, since these are much richer in information than that one.

For reasons like this, the OAS has extensions, which, in our case, will be used to describe the properties expected by the RFC as follows:

paths: (...) /users/{userId}: (...) delete: (...) deprecated: true x-deprecated-at: “2025-06-30T23:59:59Z” x-deprecated-sunset: “2026-01-01T00:00:00Z” https://api.example.com/deprecation-policy

O Parser

The function of the parsers is to read and interpret the definition file openapi.yaml, extract the relevant information for the Gateway, and create the file operations.json, which will be embedded in the image of the KrakenD and consumed during its initialization, in an approach called flexible configuration.

This is the result of operations.json:

{ "list": [ { "path": "/users", "method": "get", "backend": { "path": "/users", "host": "http://backend:8888" } }, { "path": "/users", "method": "post", "backend": { "path": "/users", "host": "http://backend:8888" } }, { "path": "/users/{userId}", "method": "get", "backend": { "path": "/users/{userId}", "host": "http://backend:8888" } }, { "path": "/users/{userId}", "method": "delete", "deprecated": { "at": "@1751327999", "link": "https://api.example.com/deprecation-policy", "sunset": "Thu, 01 Jan 2026 00:00:00 UTC" }, "backend": { "path": "/users/{userId}", "host": "http://backend:8888" } } ] }

Note that the parsers designed the extended elements of the OAS in the configuration file KrakenD, including making the appropriate value conversions, as follows:

OAS KrakenD x-deprecated-at: deprecated.at: x-deprecated-link: deprecated.link: x-deprecated-sunset: deprecated.sunset:

O Plugin

Now that the configuration of the Gateway was properly generated from the definition file, our Plugin personalized comes into play. Its function is to identify the operations of API depreciated and insert the headers of the RFC 9745 with the appropriate values.

More details can be found in the article repository.But since the Plugin was embarked on the KrakenD, we have the following results:

GET /users/1

DELETE /users/1

Note that only the second operation was depreciated (see operations.json) And Gateway correctly added the headers in the response.

Conclusions

The experiment demonstrated the viability of the concept, that is, that it is possible to take depreciation policies beyond definition and documentation, being easily communicated at runtime. In this way, systems can adopt automated actions to communicate obsolescence to interested parties and significantly reduce the chances of integration failures.

Although the extensions of the OpenAPI Specification have made this possible in view of the insufficiency of the boolean deprecated, I imagine that the OpenAPI Initiative should include an improvement in the next versions. Especially when I think that Eric Wilde, co-author of this RFC, is very active in the world of APIs.

To the readers who have made it this far, my sincere thanks. I hope these few words have added something to you and made your time worthwhile.