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
Request templating currently only supports a single body, wheras path templating supports multiple paths. Body templating needs to be improved to become consistent with path templating.
Additional context
This should be easy to implement, however I've gone back and forth with the design of how I approach this.
Path templating is easy, we can just assume that a given path is only going to be a single line and any newline characters denote a new path. We cannot assume that about request bodies though. My gut reaction was to designate a separator string (IE the yaml --- you see in k8s resources all the time), however I wasn't sure how that approach sat with me.
It seems that some smarts around the request body content / content type would be very beneficial here. If we know the body is json, and the content contains multiple json objects, then we know that we can send multiple requests with different bodies. The downside of this approach is that we would need to implement this logic for each different content type we may end up seeing, and I'm no expert on deserialization logic.
The text was updated successfully, but these errors were encountered:
Summary
Request templating currently only supports a single body, wheras path templating supports multiple paths. Body templating needs to be improved to become consistent with path templating.
Additional context
This should be easy to implement, however I've gone back and forth with the design of how I approach this.
Path templating is easy, we can just assume that a given path is only going to be a single line and any newline characters denote a new path. We cannot assume that about request bodies though. My gut reaction was to designate a separator string (IE the yaml --- you see in k8s resources all the time), however I wasn't sure how that approach sat with me.
It seems that some smarts around the request body content / content type would be very beneficial here. If we know the body is json, and the content contains multiple json objects, then we know that we can send multiple requests with different bodies. The downside of this approach is that we would need to implement this logic for each different content type we may end up seeing, and I'm no expert on deserialization logic.
The text was updated successfully, but these errors were encountered: