You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed an issue when generating mutation route schemas with the current version of SOFA. Specifically, I observed that the variables appear in both the request body and in the query parameters. You can find this behavior occurring here.
It's not clear to me what the rationale behind this behavior is. In the use case I'm working on, the more logical approach would be to place the mutation-specific variables exclusively in the request body. This would create a clear separation between the two and follow RESTful best practices more closely.
However, I understand there could be cases where query or path parameters might be necessary for routes that modify resources. So, a straightforward removal might not be the best solution.
Would it be possible to discuss this further and potentially reconsider how this is currently implemented? A configuration option to control this behavior could be one possible approach. I'm open to contributing to the solution.
The text was updated successfully, but these errors were encountered:
I've noticed an issue when generating mutation route schemas with the current version of SOFA. Specifically, I observed that the variables appear in both the request body and in the query parameters. You can find this behavior occurring here.
It's not clear to me what the rationale behind this behavior is. In the use case I'm working on, the more logical approach would be to place the mutation-specific variables exclusively in the request body. This would create a clear separation between the two and follow RESTful best practices more closely.
However, I understand there could be cases where query or path parameters might be necessary for routes that modify resources. So, a straightforward removal might not be the best solution.
Would it be possible to discuss this further and potentially reconsider how this is currently implemented? A configuration option to control this behavior could be one possible approach. I'm open to contributing to the solution.
The text was updated successfully, but these errors were encountered: