我目前的雇主使用第三方托管的CRM提供程序，并且我们在两个系统之间拥有相当复杂的集成层。 CRM提供程序的功能之一是，开发人员可以使用Java之类的语言编写业务逻辑，并在诸如用户单击按钮或者向系统中提交新帐户之类的事件时触发验证和/或者业务逻辑。

我们使用的功能之一是在托管提供程序上运行的业务代码来调用我们托管的Web服务。典型的例子是销售代表输入新的销售线索并按下一个按钮以对我们的系统执行ping命令，以查看是否可以根据电子邮件地址，公司/名字/姓氏等来识别该新的线索，如果可以，请返回代表该个人的内部GUID。所有这些对我们来说都很好，但是在尝试建立一个健全的开发环境时，我们一次又一次地碰壁。

因此，尽管我们的用例有些细微差别，但通常可以应用于为第三方使用而构建API的任何开发公司：在构建供外部使用的API时，在设计开发管道和环境时有哪些最佳实践？世界？

在我们的办公室中，我们所有的开发人员都在防火墙后面，因此，对于我们的CRM提供者来说，正在进行的代码不会受到外界的攻击。我们可以在防火墙上戳个洞，但是从安全表面积的角度来看，这并不理想。特别是如果需要在DMZ之类区域的开发人员的人数很高。目前，我们正在DMZ中尝试使用一台开发机，然后根据需要将其迁移到该工作机中，以进行开发工作，但这会导致资源短缺，如果多个开发人员需要使用此设备，更不用说他们正在进行潜在冲突的更改(例如，不同的分支机构) )。

我们已经考虑过通过为这些服务构建虚假客户端来模拟/伪造传入请求，但这是构建功能集的相当大的开销(尽管它的确可以增强我们API的可测试性)。这也没有消除这样一个事实，有时我们确实确实需要诊断/调试来自真实客户端本身的问题，而不是一些伪造的请求有效负载。

其他人在这些类型的场景中做了什么？在当今的mashup时代，必须有很多开发API的经验丰富的人-对于那里的人们来说，什么是有效的(不是很好)？

解决方案

回答

在这种情况与我相关的情况下(实话实说，这种情况并不常见)，我们倾向于将内部托管解决方案的开发副本与模拟我们无法托管的内容结合起来使用。

我个人认为，我们可以在单个开发箱上托管的主机越多，越好-如果我们开发人员的PC足够强大，可以运行整个设备以及他们需要开发的其他东西，那么他们应该这样做。它使他们拥有大量的开发灵活性，而无需担心其他人。

回答

对于开发人员而言，使用模拟对象并编写良好的单元测试来定义手头的任务将是有意义的。这将有助于确保开发人员了解业务需求。模拟库非常复杂，可以帮助解决此问题。

然后可能是一个连续的构建过程，该过程将代码移至DMZ中的dev框。强大的质量检查流程加上常规的UAT测试将是有意义的。

另外，对于常规调试，我们再次需要访问远程访问的DMZ中的计算机。

这可能是一种"理想"的情况，但是我们确实要求最佳实践:)。