将软件组件变为一种对自己有用的资源是非常容易的。这种较普遍的方法中存在的问题是容易造成过于具体化。如果你想要实现编程开关的转换功能，那么你最好设置如On和Off的动词，也许这种状态会和ReadState一样。这样固然好，但是，在API功能变得具体化的同时也会限制实施API时所使用的技术。

大多数接口会支持基本的创立、选择、更新和阅读功能。这些接口的动词信息会直接转化为超文本标记语言(HTML)、Javascript对象符号和结构化查询语言。假设你的API接口包含了这些动态功能，那么不久之后你就会完成特定接口映射的编程。

早期基于动词的方案目标是建立一种信息或者资源模型，这样就可以使用任何简便的程序或者Web/远程接口。实现这四个基本动词和避免添加其他动词非常重要，这样也许会限制所用接口的范围。你也许会建立一个程序灯，然后点亮Update或者Read开关，以这种通用的方式来完成同样的事情。

API设计中的另外一个缺陷是参数的概念。如果你查看典型的客户记录，你会看到其中包含的是API参数信息。哪些客户信息是你真的需要了解的呢？

API设计实践

如果你开始思考你想要知道的事情，那么客户参数的数量会激增，设计和开发流程也会随之扩展。更糟糕的是，当所有API都必须增加一种新的参数时，这样做会丢失客户知识，因此程序无法回到设计阶段。

最佳的方法是考虑采用自定义的数据元素。为了实现API你可以建立一种并不严格却非常灵活并可扩展的数据结构。你不必担心是否会识别数据元素，因为，你只需要简单地添加进去就可以。

如果做到了这一点，定义新数据元素之后就不必改变每一个API，因为，与数据元素相连接的API参数没有特别之处。该连接发生在应该出现的软件需求阶段，从应用程序信息模型变化的角度将API分成几个模块，包含增加新元素的变化范围。

API设计的最后一个关键点是要考虑API的自定义模块，并将其尽可能延伸到与API相连接的各部分中。不必设计一个浏览器来处理HTML界面，通过元数据与参数数据的混合来进行数据调节，以此来建立一个完整的过程描述。

API设计及其敏捷性

在应用程序设计阶段， API中同时传输元数据和应用程序数据时可能的，但是，也可能从后端数据库或者其他资源处获得远程元数据。如果可以对数据元素和与之相关的流程进行动态定义，那么应用程序开发就会更加具有敏捷特性。

将这种自定义敏捷性从API传递到应用程序各组件中是可能的。一般来说，该程序会自动处理特定的数据元素，但是，由于元数据的优势，可以使用表达式代码作为元数据来描述更复杂的流程。这就意味着完整的应用程序可以使用扩展的数据和元数据模型来完成开发项目，这样大大减少了反馈新业务问题和机会的时间。

这种程度的敏捷性对于没有大量交易的应用程序来说是非常有用的，但是，对于一些重要的任务来说又会产生过多的开销。因此，最好使用传统逻辑来处理那些总是存在或者需要很多流程的数据元素，而对于那些不常用的数据来说要使用元数据表达式。就一切情况而言，可以设计API来按需传递数据和流程。

“敏捷性”这个词已经变成老生常谈的技术了，但是，是否是这样还不好说。必须在合适的时候把握好机遇，应用程序和API也必须按照预定的计划进行安排。反思API设计可以获得更好的应用程序、敏捷性和云计算。