这两天做智能理货，一直在想一种良好的接口方案，到底哪种接口方式好。脑洞开了就收不回来，那就WebAPI吧，咱家全栈微软，那就用asp.net吧，度娘一搜，最近好像流行asp.net Core的东西，那就来一把吧，结果花了两天时间玩了一下ASP.net Core。
记下几点感受：
- 在MAC下写.net成为可能，微软威武啊。
- VS code 在全宇宙最强IDE VS的光环下，使用起来也不赖。
- asp.net Core的性能还错
- 被VS惯坏后，调试时总感觉少了点什么
- 设计理念和配置方式都向开源框架看齐了，新名词还是一如既往地加
跑偏了，还是回到接口设计上。作为一个传统企业的IT人员，一直被各种厂商玩弄，从EAI到ESB，从ESB到SOA，对于SOA的见解，我还是持保留态度。我觉得SOA就是极乐世界，你到了就是你已经挂了。但是又不能不向着它前行，就像人每天都在西天路上。
我的觉得在没法识别业务单元或者业务组件前，SOA是没法做的，SOA的理想状态就是这个业务单元或者组件趋于恒定不变，很多公司试图寻找这种恒定的元素，更多的是找不到，人为固化了一些元素，结果可想而知。
我们ESB做了好几年了，其实始终还是停留在case by case的EAI阶段。领导很有远见，似乎从一开始就意识到结果，我们叫统一数据交换平台，并不是直接叫ESB，因为这个离ESB还是有很长的距离。结果这几年的平台建设，我们实现了统一，满足了数据交换并且平台化。对于IT成熟度推进层面来说，主要体现在统一的层面，也就是在统一的层面上提升了IT的生产力。概括起来就是因管理和业务需要统一实现技术、统一实现规范、统一运维管理。
早在这个项目开始之初，我们就提出过接口标准化，这个标准化不只是实现技术和实现标准，而且要做到业务的原子性和对象颗粒化。当时我评估，纠结了好长一段时间，最终还是没有做这个项目，我的理由是既然是数据接口，还是数据数据层，既然是数据层，无论出于性能还是功能考虑，还是不要考虑上升到应用层去做对象化，既然是数据接口，如果要做数据对象化那与表对象差别不大，还不如case by case实现按需输出数据。
好像又跑偏了，现在这个数据交换平台项目设计时，我就在想下一代应该是怎么样的——我要把Biztalk替换掉。Biztalk目前只是应用容器，但是它太重了。Biztalk的流程设计器给不了我们任何好处，目前用到的只有mapping和各种接口适配器，但是这些又不能完全离开代码进行操作，所以本次统一平台的体现，虽然是基于Biztalk实现业务，实际是在Biztalk上封装了一个业务平台和管理平台，Biztalk只是一个业务容器，下一次迭代，我可以在不变更整体框架的情况下替换Biztalk，使用其它接口和数据交换容器。
跑回来了，我主要想说的之前想到的一些接口设计的点滴想法：
- WebAPI有天然的优势，负载均衡、浏览器支持、缓存、支持异步
- 使用Json
- 可以使用标准http协议的异常代码
- 面向资源构建
- 去中心化和无状态
- 版本控制
- 应用池化
- 快速失败和弹性扩展
