feat(guidelines): Add guidelines for test header usage in REST APIs
We identified that there is no rule about flagging test requests or responses of REST APIs. As we have a guideline for async events the new rules following the same approach.
Open questions in my mind to be discussed:
- Is it a good idea to use a header for responses?
- What about responses of collection APIs?
Changelog:
New
- MAY use Test header R000080
- MUST forward Test header R000081
As I'd like to support you with this PR, let me "request" these last change as I ran the script to find new available rule IDs.
According changelog suggestion:
Changelog: ### New - MAY use Test header [R000080](../api-guidelines/rest/http/headers/rules/may-use-test-header.md) - MUST forward Test header [R000081](../api-guidelines/rest/http/headers/rules/must-forward-test-header.md)
Done
Can you take a look at this PR, @thomasklinger1234 @jensfischer1515, thx :)
I read the new guideline and find it helpful.
I see additional need for communication between all involved teams if they need to differentiate processing "test" requests and regular requests. I guess there's not automatic way to do that. Should we stress this fact even more?
Hey @ccudennec-otto, do you mean communication after introducing this rule, e.g. in our TD circle? Or do mean we should add more clarification in the description of the rule itself?
Hi @maxedenharter0507 !
API consumers and providers may use the OTTO-specific
Testheader described within this rule to communicate that a request or response is part of a test.Test requests are created in various contexts. Some of them require special handling on provider or consumer side, such as bypassing specific validations or using > modified business logic while processing. This rule defines the test header that API consumers and providers can use to identify test data. Downstream teams can then forward this test header in subsequent processing steps, e.g. as a test extension in an asynchronous event.
I just wondered what happens if a team uses "Test" headers but consuming team don't consider them. As the header is not restricted to nonlive environments, it could trigger some real-world actions, couldn't it? Maybe those actions even cost real money. That's the potential risk that I see and that's why I thought we could stress this a little more.
I'm available for a chat or call - maybe it makes it easier to clarify this issue for me. 🙂