开发环境和API开发的最佳实践？
我当前的雇主使用第三方托管的 CRM 提供商，并且我们在两个系统之间拥有相当复杂的集成层。 CRM 提供商的功能之一是让开发人员以类似 Java 的语言编写业务逻辑，并在用户单击按钮或向系统提交新帐户等事件时触发验证和/或业务逻辑。
我们使用的功能之一是让在托管提供商上运行的业务代码调用我们托管的 Web 服务。 典型的示例是销售代表输入新的销售线索，然后点击按钮来 ping 我们的系统，看看我们是否可以根据电子邮件地址、公司/名字/姓氏等识别该新线索，如果是，则返回代表该个人的内部 GUID。 这一切对我们来说都很好，但是在尝试设置一个健全的开发环境来工作时，我们一次又一次地遇到了困难。
因此，虽然我们的用例有点微妙，但这通常适用于为第 3 方使用构建 API 的任何开发公司：在构建要使用的 API 时设计开发管道和环境时有哪些最佳实践被外界攻击？
在我们的办公室，我们所有的开发人员都位于防火墙后面，因此正在进行的代码不会受到外界（在我们的例子中是 CRM 提供商）的攻击。 我们可以在防火墙上挖洞，但从安全面的角度来看，这并不理想。 特别是如果需要处于 DMZ 之类区域的开发人员数量较多的情况下。 我们目前正在 DMZ 中尝试使用一台开发机器，然后根据需要远程连接到它来进行开发工作，但是如果多个开发人员需要该盒子，就会产生资源稀缺问题，更不用说他们正在进行潜在冲突的更改（例如不同的分支） ）。
我们考虑过通过为这些服务构建虚假客户端来模拟/伪造传入请求，但这是构建功能集的相当大的开销（尽管它本质上增强了我们 API 的可测试性）。 这也并不能消除这样一个事实：有时我们确实需要诊断/调试来自真实客户端本身的问题，而不是一些伪造的请求负载。
其他人在这些类型的场景中做了什么？ 在当今混搭时代，一定有很多人拥有开发 API 的经验——什么对这些人来说有效（或无效）？
My current employer uses a 3rd party hosted CRM provider and we have a fairly sophisticated integration tier between the two systems. Amongst the capabilities of the CRM provider is for developers to author business logic in a Java like language and on events such as the user clicking a button or submitting a new account into the system, have validation and/or business logic fire off.
One of the capabilities that we make use of is for that business code running on the hosted provider to invoke web services that we host. The canonical example is a sales rep entering in a new sales lead and hitting a button to ping our systems to see if we can identify that new lead based on email address, company/first/last name, etc, and if so, return back an internal GUID that represents that individual. This all works for us fine, but we've run into a wall again and again in trying to setup a sane dev environment to work against.
So while our use case is a bit nuanced, this can generally apply to any development house that builds APIs for 3rd party consumption: what are some best practices when designing a development pipeline and environment when you're building APIs to be consumed by the outside world?
At our office, all our devs are behind a firewall, so code in progress can't be hit by the outside world, in our case the CRM provider. We could poke holes in the firewall but that's less than ideal from a security surface area standpoint. Especially if the # of devs who need to be in a DMZ like area is high. We currently are trying a single dev machine in the DMZ and then remoting into it as needed to do dev work, but that's created a resource scarcity issue if multiple devs need the box, let alone they're making potentially conflicting changes (e.g. different branches).
We've considered just mocking/faking incoming requests by building fake clients for these services, but that's a pretty major overhead in building out feature sets (though it does by nature reinforce a testability of our APIs). This also doesn't obviate the fact that sometimes we really do need to diagnose/debug issues coming from the real client itself, not some faked request payload.
What have others done in these types of scenarios? In this day and age of mashups, there have to be a lot of folks out there w/ experiences of developing APIs--what's worked (and not worked so) well for the folks out there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这与我相关的情况下（说实话，这种情况并不常见），我们倾向于将内部解决方案的开发副本托管与模拟我们无法托管的内容相结合。
我个人认为，您可以在单个开发设备上托管的设备越多越好 - 如果您的开发人员的 PC 足够强大，可以运行整个系统以及他们需要开发的其他内容，那么他们应该这样做。 它使他们能够拥有大量的灵活性来发展，而不必担心其他人。
In the occasions when this has been relevant to me (which, truth be told, is not often) we have tended to do a combination of hosting a dev copy of the solution in-house and mocking what we can't host.
I personally think that the more you can host on individual dev boxes the better-- if your dev's PCs are powerful enough to have the entire thing running plus whatever else they need to develop then they should be doing this. It allows them to have tonnes of flexability to develop without worrying about other people.
对于开发人员来说，使用模拟对象并编写定义手头任务的良好单元测试是有意义的。 这将有助于确保开发人员了解业务需求。 模拟库非常复杂，有助于解决这个问题。
然后可能是一个连续的构建过程，将代码移动到 DMZ 中的开发盒。 强大的 QA 流程加上一般的 UAT 测试是有意义的。
另外，对于一般调试，您再次需要访问您远程进入的 DMZ 中的计算机。
这可能是一个“理想”情况，但您确实要求最佳实践:)。
For dev, it would make sense to use mock objects and write good unit tests that define the task at hand. It would help to ensure that the developers understand the business requirements. The mock libraries are very sophisticated and help solve this problem.
Then perhaps a continuous build process that moves the code to the dev box in the DMZ. A robust QA process would make sense plus general UAT testing.
Also, for general debugging, you again need to have access the machine in the DMZ where you remote in.
This is probably an "ideal" situation, but you did ask for best practices :).