Skip to content

Conversation

kendallb
Copy link
Contributor

Description

Fix for #1816

Purpose

This pull request is a:

  • Bugfix (non-breaking change which fixes an issue)

Checklist

  • I have added tests that prove my fix is effective or that my feature works

@kendallb kendallb force-pushed the feature/manual-body-content-1816 branch 2 times, most recently from 0854302 to 7d10290 Compare March 31, 2022 21:37
@kendallb kendallb force-pushed the feature/manual-body-content-1816 branch from 7d10290 to 8e27df0 Compare April 4, 2022 16:19
ParameterType.UrlSegment => new UrlSegmentParameter(name!, value?.ToString()!, encode),
ParameterType.HttpHeader => new HeaderParameter(name, value?.ToString()),
ParameterType.RequestBody => new BodyParameter(name, value!, Serializers.ContentType.Plain),
ParameterType.RequestBody => new BodyParameter("", value!, string.IsNullOrEmpty(name) ? Serializers.ContentType.Plain : name!),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That will break things. Unlike RS 106, the latest version allows you to add multiple body parameters. It works with multipart form data. There, parameters must have names, also body parameters.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, not sure I like the fix either but so much code does it that way :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is: do we want to make it compatible or force people to use the right API. In the latter case, we can throw an exception if the parameter name looks like content type, and the exception would say: "it won't work, use AddStringBody". I can add an overload for AddStringBody that would accept the parameter name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s a good idea. For us it took a long time to figure out what was wrong as I had to inspect the outgoing packets to finally work out it was not sent with the right content type. A logical exception explaining what is wrong would save those folks with the same problem a lot of time.

alexeyzimarev added a commit that referenced this pull request Jun 7, 2022
alexeyzimarev added a commit that referenced this pull request Jun 7, 2022
alexeyzimarev added a commit that referenced this pull request Jun 7, 2022
* Replacement for #1817

* Added the test from #1817

* Allow also adding properly named body parameters
@alexeyzimarev
Copy link
Member

I made a similar change in #1869 and kept the ability to add named body parameters. The check looks like a hack as it's based on looking for a slash in the parameter name. Hope it will solve some of the issues. I got a bit tired of all the complaints, and, honestly, until SwaggerGen and Postman code generators get fixed (which I don't expect to happen soon), these complaints will keep copming.

@kendallb
Copy link
Contributor Author

kendallb commented Nov 8, 2022

Checked #1869 and it looks like a good solution for me. Deleting my branch.

@kendallb kendallb deleted the feature/manual-body-content-1816 branch November 8, 2022 15:24
@alexeyzimarev
Copy link
Member

Btw, Postman is being updated, they asked me to review the new generator version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants