已经定义了 400 为成功，无法获取响应体内容，其实是有 JSON 返回数据的
私有部署版本： 3.7.1
集成API中，当httpCode为400时，无法获取响应体内容
19 / 666
有1人点赞 有1人点赞
请
登录后发表观点
明白了。这个问题我跟一下，在后续版本中处理。
这问题麻烦跟进下哦，谢谢
明白了。这个问题我跟一下，在后续版本中处理。
3.8.2 的私有部署版本里，该问题依然存在
之前的 bug 已经处理，您可以验证一下。
另外您说的 PBP 开启 API 后的异常分支是指什么意思？是指返回异常值给到请求方吗？
我试了下，最新的私有部署 3.8.1 版本里，还没修复这问题是把？
好的谢谢！
- PBP 开启平台 API
- PBP 中使用 API 调用
那么当 API 发生异常时，会导致 PBP 流程执行失败，目前无法控制在 API 调用失败时通过平台 API 输出结果的，工作流会执行中断
明白了。这个问题我跟一下，在后续版本中处理。
之前的 bug 已经处理，您可以验证一下。
另外您说的 PBP 开启 API 后的异常分支是指什么意思？是指返回异常值给到请求方吗？
好的谢谢！
- PBP 开启平台 API
- PBP 中使用 API 调用
那么当 API 发生异常时，会导致 PBP 流程执行失败，目前无法控制在 API 调用失败时通过平台 API 输出结果的，工作流会执行中断
好的，感谢感谢！
还有个问题麻烦一起考虑下，PBP 里是不是需要支持 API 的异常分支，目前是没办法处理的，工作流会直接报错，对于开启平台 API 的 PBP 就有点难受了
之前的 bug 已经处理，您可以验证一下。
另外您说的 PBP 开启 API 后的异常分支是指什么意思？是指返回异常值给到请求方吗？
已上报 bug，接下来的更新会处理这个问题。
好的，感谢感谢！
还有个问题麻烦一起考虑下，PBP 里是不是需要支持 API 的异常分支，目前是没办法处理的，工作流会直接报错，对于开启平台 API 的 PBP 就有点难受了
所以我说这可能是个 bug，你们要不验证下看看，测试下来只要出了 400 就 body 里的值就取不到
已上报 bug，接下来的更新会处理这个问题。
那您只需要配置 200 的正常结果就可以了，把 400 配置到正常请求代码中，执行时如果出现 400 状态，后续的业务处理可以去使用这些 code 和 msg 的。
所以我说这可能是个 bug，你们要不验证下看看，测试下来只要出了 400 就 body 里的值就取不到
那您只需要配置 200 的正常结果就可以了，把 400 配置到正常请求代码中，执行时如果出现 400 状态，后续的业务处理可以去使用这些 code 和 msg 的。
是啊。我是这么配置的，但是确实不工作。。只要出了 400，工作流里取到的对应响应字段全是空。
以下是实际请求，200：
400：
是的，我和您理解是一致的。现在的问题在于 400/500 和 200 的返回结构是一致的，但是 400/500 时候并不能正确解析出 body 结构。这是实际的 API 接口响应示例，我可以把调用方式提供你们测试下
那您只需要配置 200 的正常结果就可以了，把 400 配置到正常请求代码中，执行时如果出现 400 状态，后续的业务处理可以去使用这些 code 和 msg 的。
这个问题是这样的：我们对请求的返回值，只支持一种结构，多数情况下是正常请求（200）的结果，方便后续业务处理。如果要处理 400 这类异常的返回结构，只要结果中返回了和 200 结果一样的字段，后续仍然是可以处理的。如果 400 异常返回的 JSON 是完全不同于 200 的结构，那是没办法在后续的处理中正常使用的，因为这样会破坏正常请求的业务逻辑。
所以还是要看你的 400 和 200 返回的结果中，是否有相同的字段比如错误码 errorcode 和错误消息 errormsg，如果有，那业务就是可以正常去执行和判断的。这里在配置时，只需要考虑 200 的结果可以测试成功即可。如果返回的结果完全不同，那目前我们是无法支持的，即使支持了，也会导致正常请求的逻辑无法执行，得不偿失了。
是的，我和您理解是一致的。现在的问题在于 400/500 和 200 的返回结构是一致的，但是 400/500 时候并不能正确解析出 body 结构。这是实际的 API 接口响应示例，我可以把调用方式提供你们测试下
因为有些 API 的错误数据，不是通过 200 状态吗返回的，也是正常的
这个问题是这样的：我们对请求的返回值，只支持一种结构，多数情况下是正常请求（200）的结果，方便后续业务处理。如果要处理 400 这类异常的返回结构，只要结果中返回了和 200 结果一样的字段，后续仍然是可以处理的。如果 400 异常返回的 JSON 是完全不同于 200 的结构，那是没办法在后续的处理中正常使用的，因为这样会破坏正常请求的业务逻辑。
所以还是要看你的 400 和 200 返回的结果中，是否有相同的字段比如错误码 errorcode 和错误消息 errormsg，如果有，那业务就是可以正常去执行和判断的。这里在配置时，只需要考虑 200 的结果可以测试成功即可。如果返回的结果完全不同，那目前我们是无法支持的，即使支持了，也会导致正常请求的逻辑无法执行，得不偿失了。
这是 200 状态码的 body 数据，已经保存过了，但是遇到 400/500 的时候，确实是拿不到 body 里的数据，都是空，但实际响应是存在的
可能返回数据的问题 返回需要时 JSON 不是 text
这问题能帮忙看看吗，本来对接个 API 应该是挺简单的事情，搞的有点麻烦了
这是 200 状态码的 body 数据，已经保存过了，但是遇到 400/500 的时候，确实是拿不到 body 里的数据，都是空，但实际响应是存在的
需要先保存一次，配置才生效
因为有些 API 的错误数据，不是通过 200 状态吗返回的，也是正常的
需要先保存一次，配置才生效
这问题能帮忙看看吗，本来对接个 API 应该是挺简单的事情，搞的有点麻烦了
需要先保存一次，配置才生效
保存是保存过的了，这问题像是个缺陷，只有 200 才能拿到 body，非 200 就拿不到 body 内容，导致工作流节点里没办法做后续判断，因为也没有失败分支可以用
需要先保存一次，配置才生效