和API构建相关的常被忽略的问题是，应该使用哪种技术构建API？通常来说，关于语言或者托管方式的决策有些一厢情愿。对于用C#编写的应用，很可能就用C#编写API，并且托管在互联网信息服务里。基于Java的应用很可能用Java编写其SOAP或者REST API，并且托管在J2EE容器里。

对于任何应用而言，基于Web的API通常在应用本身的stack里构建。这似乎已经成为一种常识。API团队和应用团队可能就是同一个团队。除了共享技能和知识，可能还需要在应用的用户和API客户端之间共享基础架构。这是最好的方式吗？

为公开API的构造选择不同的开发语言，需要考虑如下领域：

• 托管。一个应用的内部托管环境是针对已有内部用户而优化的。这样的环境是否能够同时支持外部客户或者完全是重复的，它并不是为API所需的不同级别的使用而设计的。最好的情况是只是API的性能有些差，但是最坏的情况呢？会影响已有用户。
• 安全性。应用及其API错综复杂。API只能暴露被底层系统完整支持的功能。当使用相同语言编写API和应用时，就有可能在两者之间漂移。

这是很容易的进攻方式。开发人员加强或者修复某段被已有API方法使用的代码。开发人员测试前端—但是并没有测试API—来确认改变已经成功了。但是如果只有前端测试用例的成功并不意味着API没有改动受影响。应用的改动可能会向外部暴露一些不需要的信息或者影响API性能。负责API构造以及测试的单独团队必须确定并在常规开发周期里考虑到如何预防API 漂移的发生。

• 稳定性。在过去的这些年里，一些平台更容易重载数据或者被恶意攻击。如果在内部运行这些平台的其中之一，可能不需要担心什么。但是一旦它们在防火墙的另一端工作，就需要多加注意了。
• 质量。要记住优秀的设计意味着对客户的深度理解。当主要的应用和API是由同一个团队在同一个平台上开发出来的时候，API会倾向于过度反应应用程序的结构。这通常和外部开发人员需要的API相去甚远。

外部开发人员不熟悉应用的编写方式，不知道如何将一系列API调用组合起来来完成某个特定目标。他们是不同类型的客户，也需要特别考虑到他们的需求。在不同平台上构造API需要尽量保持当前产品及其API的一致性，否则可能就会引入API驱动的风险。多个团队的结构有助于通过私下内部的交流来优化API，而不是通过公开论坛来沟通。

当然还有其他原因促使在别的平台上托管API，比如，在API驱动遗留技术的时候可能就别无选择。可能使用其他的语言更容易找到合适的技术人员，并且得到更好的性能。此外，可能会使用商品基础架构或者更好的许可证协议。

一些大公司已经拥有了跨多个平台的技能和资产，因此决定使用不同的语言来构造API并不显得牵强。小型企业可能不会倾向于雇佣并培训新员工来构建新的基础架构。讨论另外的可选语言没有什么坏处，但是如果已经决定开发并部署到统一的平台上，这样的讨论可能仅仅能够帮助发现弱点。