|
|
反思API设计 让应用更敏捷更云化项目团队曾经以组件集合的形式进行项目开发，因此会将关注点集中于绑定这些组件的接口上，即应用程序接口(API)。因特网和Web服务器的出现为API增添了很多色彩。 将软件组件变为一种对自己有用的资源是非常容易的。这种较普遍的方法中存在的问题是容易造成过于具体化。如果你想要实现编程开关的转换功能，那么你最好设置如On和Off的动词，也许这种状态会和ReadState一样。这样固然好，但是，在API功能变得具体化的同时也会限制实施API时所使用的技术。 大多数接口会支持基本的创立、选择、更新和阅读功能。这些接口的动词信息会直接转化为超文本标记语言(HTML)、Javascript对象符号和结构化查询语言。假设你的API接口包含了这些动态功能，那么不久之后你就会完成特定接口映射的编程。 早期基于动词的方案目标是建立一种信息或者资源模型，这样就可以使用任何简便的程序或者Web/远程接口。实现这四个基本动词和避免添加其他动词非常重要，这样也许会限制所用接口的范围。你也许会建立一个程序灯，然后点亮Update或者Read开关，以这种通用的方式来完成同样的事情。 API设计中的另外一个缺陷是参数的概念。如果你查看典型的客户记录，你会看到其中包含的是API参数信息。哪些客户信息是你真的需要了解的呢？ API设计实践 如果你开始思考你想要知道的事情，那么客户参数的数量会激增，设计和开发流程也会随之扩展。更糟糕的是，当所有API都必须增加一种新的参数时，这样做会丢失客户知识，因此程序无法回到设计阶段。 最佳的方法是考虑采用自定义的数据元素。为了实现API你可以建立一种并不严格却非常灵活并可扩展的数据结构。你不必担心是否会识别数据元素，因为，你只需要简单地添加进去就可以。 责编：李玉琴  微信扫一扫实时了解行业动态 著作权声明：畅享网文章著作权分属畅享网、网友和合作伙伴，部分非原创文章作者信息可能有所缺失，如需补充或修改请与我们联系，工作人员会在1个工作日内配合处理。 |
推荐博客 |
POEM Experiments 2.0 Brochure ...|
|
