是时候停止将 ColdFusion 用于远程 API 了吗？

所以，让我先说我有点沮丧，所以这篇博文可能是我后来后悔的一篇，但是，我现在和现在都尽量诚实，我有点生气了我想把它从我的胸口拿走。很长一段时间以来，我一直非常尊重 Coldfusion 如何让从客户端代码（或远程服务器）访问数据变得容易。这些天我在研究 node.js，事实上我可以编写一个 cfc 并获得一个可以被 javascript 使用的 api，这是非常强大的。此功能已经取得了长足的进步。当它刚出来的时候，输出的唯一选项是 wddx。您现在可以输出任何内容，从 wddx 到 soap，再到 xml、纯字符串，当然还有 json。

事实上，我非常喜欢这个功能，所以我在今年的 Coldfusion 峰会上为此提出了一个主题。我的会议将概述如何为远程消费生成输出，并涵盖从开始（coldfusion mx 和更早版本）到即将发布的版本 (12) 的所有内容。

然而…

自从 coldfusion（coldfusion 8）中开始支持本机 json 以来，序列化一直存在问题。这一切都源于 coldfusion 变量是无类型的，因此服务器必须（或者确实如此？）猜测如何将值转换为 json。在过去的三个版本中，我看到了多个错误和多个修复，虽然我没有真正的证据（稍后会详细介绍），但我的直觉告诉我事情已经缓和了一点，而 Coldfusion 11 有这个问题舔了。

或者我想。

事实证明，错误 3337394 是将近三年前创建的，哦，一个标记为已关闭并已修复的错误，对于序列化来说仍然是一个非常大的问题。如果您在结构中有数据，并且它具有字符串值“no”，coldfusion 会将其转换为 false。这是一个示例：


 x = {"name":"no"};
y = querynew("id,name", "integer,varchar", [{"id":1, "name":"ray"},{"id":2, "name":"no"}]); 
writeoutput(serializejson(x));
writeoutput("
");
writeoutput(serializejson(y,"struct"));

这给你：


 x = {"name":"no"};
y = querynew("id,name", "integer,varchar", [{"id":1, "name":"ray"},{"id":2, "name":"no"}]); 
writeoutput(serializejson(x));
writeoutput("
");
writeoutput(serializejson(y,"struct"));

如您所见，结构已损坏，查询工作正常。（正如错误本身所报告的那样。）

另一个问题涉及包含数字的字符串。考虑这两个例子：


 x = {"name":"no"};
y = querynew("id,name", "integer,varchar", [{"id":1, "name":"ray"},{"id":2, "name":"no"}]); 
writeoutput(serializejson(x));
writeoutput("
");
writeoutput(serializejson(y,"struct"));

这返回：


 x = {"name":"no"};
y = querynew("id,name", "integer,varchar", [{"id":1, "name":"ray"},{"id":2, "name":"no"}]); 
writeoutput(serializejson(x));
writeoutput("
");
writeoutput(serializejson(y,"struct"));

如您所见，productkey 现在是一个数字，并且将在 javascript 中转换为 8.990090913093909e+34。

所以…。是的。在所有情况下，都有解决方法。但让我问你这个。您会使用随机更改您的值的数据库吗？

现在这仍然是一个问题，这似乎很荒谬。这可能非常困难。哎呀，我不会假装能够解决它。但这里有一些建议：

显然，coldfusion 团队对此进行了单元测试。他们一定。因此，当单元测试针对在 bug 中发现的项目进行更新时，请与我们分享。我知道社区中有很多人愿意花时间帮助充实单元测试，或者见鬼，就把它放在本地并在新版本出现时进行测试。所以这是我的第一个请求——让我们看看 json 序列化的测试。说到单元测试，上次修复了这个bug，为什么不立即分享测试呢？我的意思是，我们不会看到它起作用，但我向那些问过为什么涉及数据序列化的 bug 的测试只测试查询（我相信还有 cfc）的人保证。我不想对解决此问题的工程师喋喋不休——我们都会犯错——但为什么不在编写测试时发布并与我们分享呢？当然，人们可以写一篇关于错误跟踪器上有时会发生的缺乏沟通的文章，这真是一种耻辱。你知道，我知道有些人不喜欢参与或者基本上很害羞。但没有任何借口了。我也很害羞。当有人跟我说话时，我必须努力用自己的问题来回答他们的问题。我认识到我缺乏参与基本的人际交往，并强迫自己解决我缺乏社交技能的问题。列一个清单，贴在显示器旁边的便利贴上。 “当我修复一个错误时，请详细说明我是如何修复它的，我是如何测试它的，以及我可能担心的事情。记者可能有很好的意见！”
鉴于 Coldfusion 的“胶水”方面是其最大的卖点之一，将 json 序列化作为 Coldfusion 12 的优先事项。显然这个问题还没有解决，好吧，好吧，已经好几年了，但很好。 coldfusion 12 路线图这样说：“管理、监控、调节、保护休息和 soap 网络服务的能力——api 管理”。在我管理我的 api 之前，我希望 100% 确定它们确实正确地处理了数据。
嘿——核选项怎么样？如果冷聚变变量的本质意味着问题不是 100% 可解决的，则删除该特征。严重地。好吧，也许这有点过头了，但是现在 coldfusion 中有些东西已经有一段时间没有更新了，看起来被遗弃了，也许应该被删除。因此，如果他们无法修复它，请将其删除。

所以我用一个有点大胆的标题开始了这篇博文——是时候停止对远程 api 使用 coldfusion 了吗？我们社区中的许多人已经反对使用 coldfusion ui 功能。如果我们不能相信来自 cf 内置 json 序列化的数据，那么是时候完全停止使用它了吗？你怎么认为？

ps 不要忘记你可以切换到 nadel 的优秀 jsonserializer.cfc 。

ps 在上面我指出了 coldfusion 必须猜测数据类型。 adam cameron 在 bug 中对此做出了很好的评论：“你说得很好，peter：这很不方便，但明白 cf 无法在这种情况下推断数据类型，所以 - 在此基础上 - *不要尝试*。如果你知道你不能做某事……就不要继续尝试去做。”假设“no”是一个字符串，不要转换它。如果有人在他们的数据中使用 no 表示错误，那么为什么不惩罚他们而不是其他人呢？

ps 在我写这篇文章的时候，我突然想到我们还有其他地方的数据有点模糊。例如，数学会大量分解。我知道这是其他语言的一个问题，当然我们不应该因此而从 coldfusion 中删除算术，但它感觉就像是一个与我在 json 序列化中看到的不同的领域。

是时候停止将 ColdFusion 用于远程 API 了吗？

相关文章