Content-Type header added despite no request body defined in POST/PUT/PATCH endpoints

[nikrooz]

Context

This bug affects POST/PUT/PATCH endpoints that lack a request body. When a request is made, a Content-Type: application/json header is added, which can cause an error in the API as it attempts to decode a nonexistent request body.

Current Behavior

The "Try-it" feature and example snippets add a Content-Type: application/json header to the request, even when no request body is specified in the spec for POST/PUT/PATCH endpoints.

Expected Behavior

If no request body is defined, the Content-Type header should not be included.

Possible Workaround/Solution

• I understand there was a similar issue (Try-it: Content-type added even when no request body defined #2351) and a fix (Add Content-Type and Accept headers where necessary #2349), but from what I can tell, the fix only applies to GET endpoints.
• From what I gathered
  • shouldIncludeBody here is resolved to true as bodyInput is "".
  • Ultimately, the bodyInput comes from here ,which is set to "" in here when the mediaTypeContent is undefined which is the case when there is no requestBody.
• It seems the simplest solution is to return undefined from generateExampleFromMediaTypeContent when mediaTypeContent is undefined. If this is actually the solution, happy to make a PR.

Steps to Reproduce

1. Use this spec openapi.json in https://elements-demo.stoplight.io/
2. You'll see the example curl snippet include Content-Type

3. And the request from Try it includes `Content-Type` header

Environment

• Version used: 8.4.7
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):
• Link to your environment/workspace/project:

[mnaumanali94]

@nikrooz Happy to review if you create a PR. Out of curiosity what is the usecase for a PUT/POST without a request body?

[nikrooz]

Thanks @mnaumanali94.

I'm not an expert in API design, but while it's uncommon to use a POST request without a body, it can be useful in certain scenarios. For example, consider POST /workflows/{id}/run, where the request triggers a state change. In this case, using POST is ideal because it indicates a mutation, even though no additional information is needed in the body.

Our use case is slightly more nuanced. In our situation, "getting" a resource induces side effects, including some state changes. Therefore, using POST is beneficial to accurately represent these side effects in the API and ensure the correct caching behavior.

I have opened #2739, please have a look when you have a moment. Thanks for your help.