json - 非标准 JSON 和 Azure 逻辑应用

Question

我有一个可以生成如下 JSON 的 API:

)]}',

{
    //JSON DATA
}

//JSON DATA 是有效的 JSON，但顶部的 )]}', 不是。

当我尝试通过逻辑应用获取此数据时，我得到:

BadRequest. Http request failed: the content was not a valid JSON.

所以，一些相关问题:

1) 我是否可以告诉逻辑应用返回无效的 JSON？

2)如何更好地调试问题？我碰巧知道该响应无效，但如果我不知道怎么办？我可以在某处查看原始数据吗？

3) 这一切都是通过 Azure Web 门户完成的。有更好的工具吗？ Visual Studio ？

我还应该提到，如果我在同一 API 上调用返回 XML 而不是 JSON 的路由，则逻辑应用程序可以正常工作。所以它肯定不特别喜欢 JSON 响应。

谢谢!

Answer 1

首先，请不要将三个问题作为一个问题发布。

<小时/>

问题 1)。您能做的最好的事情就是让 API 返回一个有效的 JSON 对象。这有数百万个理由。这里有一些:

• 这几乎是一个标准(有效的 JSON 或 XML——是的，老派的方式)；
• 因此，此 API 的任何用户(包括您)都无需费力猜测发生了什么及其原因；
• 您的逻辑应用的步骤将正常工作，而不会增加额外的复杂性；
• 你会让这个世界和你的业力变得更好。

如果 API 端的更改不在您的能力范围内，我认为您无能为力。如果您幸运并且 HTTP 操作成功(状态代码 2xx)，您可以尝试使用 Query Action使用截断第一个字符的函数。它看起来像这样(我不知道确切的语法):@Substring(body('myHttpGet'), 4, length(body( 'myHttpGet')) - 4) 其中 myHttpGet 是 Http Get 操作的 ID。

但是，如果可能的话，我再次强烈建议修复问题的根本原因 API，而不是在此之后处理垃圾响应。

更新您可以做的另一件事是包装脏 API。例如，您可以创建一个简单的 Azure 函数，该函数调用您不直接控制的 API，并根据您的消费需求清理响应。此 Azure Function 函数应该很容易从逻辑应用程序调用。它几乎不需要任何成本(除非我们谈论的是每月数百万个请求)。这里唯一的缺点是延迟增加，这可能根本不是问题——测试一下，看看它是否增加了不到 100 毫秒左右的时间……哦，别忘了向 API 所有者提交票证，他们让我们的世界变得糟糕!

<小时/>

问题2)在Azure Logic App Web UI中，您可以查看执行详细信息，肯定会出现错误。

<小时/>

问题 3)您要求提供工具推荐，这从定义上来说是一个高度主观的事情，并且与 StackOverflow 上的主题无关。