凭API搭桥铺路　企业应用直达云端

API是企业直达云端应用殿堂的天梯

前言：
当企业决定导入云端服务，此后不论是应用程序开发者、用户端应用程序开发者、部署者、管理者，乃至于云端供应者，皆必须与此云端接轨，其间赖以互通无虞的桥梁，即是应用程序界面(Application Programming Interface；API)，一旦有了API的辅助，上述各类型开发者都可化繁为简，大幅省却开发的负担、时间与成本。

本文：
从美国国家标准与技术研究院(NIST)释出「云端运算工作定义」后，原本大家对于云端运算之纷歧认知，开始定于一尊，确定云端运算拥有SaaS、PaaS与IaaS等三种服务模式，也拥有公有云、私有云、混合云与社群云等四种部署模型，再加上「高度弹性」、「运算服务」、「随需应变自助服务」、「网络使用无所不在」及「资源汇整」等五种基本特性。

随着NIST标准定义的出炉，佐以相关解决方案、应用案例接续现身，至此云端运算的轮廓渐趋清晰，有助于化解众家企业的诸多疑虑，愿意敞开心胸、投入云端应用的用户，已见大幅增加。

然尽管企业高层主管，对于云端运算兴致勃勃，但其麾下必须奉命行事的开发人员，或许基于对云端内涵之不够了解，难免眉头深锁，视为畏途，因为云端程序既然得执行在大量经虚拟化的分散式运算架构，那麽其所对应的设计、开发、测试与验证准则，必然迥异于自己过去的所见所闻，如此一来，先前相对单纯的工作内容，肯定会变得复杂许多，此时面对茫然不知的前路，还真的不知该如何做，才能走得又快又稳。

事实上，这些满怀忧虑的开发者，之所以有所迟疑，也不是没有几分道理，并非全然是庸人自扰，但他们也许轻忽了API的妙用，也就是当你决定采用哪一家云端服务，便可以藉由该供应商所提供的免费或要价不高之API，轻松搞定诸如程序码回应、签章运算…等大大小小琐事，甚至联网络内部的数据格式与结构，也都有类似工具箱的机制代为处理，绝无开发者原本认知之劳心劳力；由此可见，API对于想要上云的企业，真的就像是跨越鸿沟的桥梁。

欲与云端互动，少不了API
API是什麽呢？简言之，它是一种协议，可以明明白白地告诉开发者，需要如何撰写程序码，才能与其所对应的特定系统互动；究竟API告诉了开发者哪些事？除了系统运作所支持的语法外，还会针对每一项作业，阐明应当传送哪些信息给系统，而系统收到后，会回覆怎麽样的信息，并事先提醒未来可能出现的潜在错误，除此之外，API也涵盖了譬如HTTP等通讯协定，或者譬如XML SCHEMA等数据格式。

至于定义API所应采用的程序语言，范围其实很广，比方说，未必具有机器可读语言的REST法，即便如此，仍可被用以定义API，其余例如Web服务描述语言(Web Services Description Language；WSDL)、界面定义语言(Interface Definition Language；IDL)，当然也很适合。

API在理解数据或作业的意涵时，需要根据参数予以识别，而参数通常表徵于两组整数，得先由开发者自行定义这两个整数，再由机器据此判读参数，最终回馈成为数据及作业的语意。

根据Open Cloud Manifesto.org提供的文件，建立云端应用服务的API，基本上可区分为四个层级或五种型态。有关四个层级，层级由浅而深，依序是网络、特定语言工具箱、特定服务工具箱及非特定服务工具，层级之不同，意谓开发所需关注的任务或数据属性，皆有所区别；举例来说，若采用层次最低的「网络」级API，开发者可直接撰写网络格式的请求，且不论该服务植基于REST或SOAP都可，但以REST而论，开发者藉由HTTP标头信息、请求内容之建立，接着开启连结服务的HTTP，而服务供应端接收信息后，即会回覆数据并附带HTTP回应码，整段历程一气呵成，显见在网络层级撰写与REST服务相关之程序码，效率确实很高。

反观SOAP服务，开发人员则需建立SOAP信封、附加SOAP标头，然后把数据内容置入这个主体，而服务供应端回覆时，系以SOAP信封装载请求结果，看来与REST服务颇为神似，但内涵并不相同，因为SOAP服务涉及XML内容的解析，情况相对复杂，比较适合藉由更高层次来的执行。

一旦进入特定语言工具箱层次，开发者即便仍须按照REST或SOAP服务的需求，专注处理网络里头的数据格式与结构，但若论及处理回应程序码，或者是计算验证签章等事项，都不再需要亲力亲为，工具箱可自动代为处理。

可以想见，层次更高一级的特定服务工具箱，API所能做到的事情，肯定愈来愈多；在此前提下，开发者仅需要关注于企业组织的数据及流程，可无须理会网络协定，应用开发效能自然更大。

最高层级的API－非特定服务工具箱，情况大致与前一级的特定服务工具箱相若，但两者不同之处在于，非特定服务工具箱所意谓的是众多云端供应商的共同界面，而不是仅适用于特定场域，因此对于开发者更加省事，由此撰写的应用程序，现今可套用于A供应商，未来还能移转至B、C、D…等不同供应商，原应用程序可能完全无须改写，或仅需些许更动即可。

开发角色有别，适用不同API
另外谈到Open Cloud Manifesto.org所定义的五种类别API，分别是一般程序设计、部署、云端服务、映像档暨基础架构管理、内部界面。先说内部界面，意指云端基础架构不同区之间的内部程序界面，举例来说，若企业想从A供应商转换跑道到B供应商，就需要采用此类API。

在映像档暨基础架构管理部分，则着重虚拟机器映像档及基础架构之管理，举凡有关虚拟机器映像档的API支持上传、启动部署、停止部署、重启部署、删除映像档等功能，以及诸如网络、防火墙、运算节点、负载平衡等基础架构管理细项，都落在此范围内。

至于云端服务，意指与云端服务应配合的程序界面，此类API可对应于常见的云端数据库、云端储存服务或云端信息伫列等等不同服务，型态琳琅满目。

部署方面，顾名思义，即是企业将其应用程序部署在云端的界面，内含譬如EAR(Enterprise Archive)、JAR(Java Archive)或WAR(Web Archive)，或.NET元件等传统惯用之封装技术，此外也涵盖了云端运算的特殊封装机制。

有关一般程序设计，指的就是类似Java、C#或PHP等API，过去在非云端环境，就经常出现这些API，如今进入云端时代，其实前后并无太大差异，等于是五类API当中最为中性者。

一开始曾提到，举凡应用程序开发者、用户端应用程序开发者、部署者、管理者或云端供应者等不同型态的开发者，都需要因应与云端系统的互通，采用必要的API，各个角色与上述五大类API的对应关系如何？应用程序开发者部分，会使用到一般程序设计、或云端服务等API；而负责撰写用户端应用程序的开发者，则适用于云端服务API。

肩负包装、部署与维护云端应用之任务的部署者，抑或管理者，两类角色定位需求较为近似，可能都需要因应云端应用的生命周期循环，在不同阶段采用到不同API，不管是部署型API、云端服务型API或是映像档暨基础架构管理型API，都将派上用场。最后谈到的云端供应者，则经常运用其云端供应项目下的基础架构，因此对于内部界面型API，具有颇高的使用需求。