API管理工具能否彌補REST與Web服務之間的鴻溝？
隨著企業學習如何通過RESTful利用現有服務，API管理工具正在引起轟動。
企業面臨許多源自SOA架構好處的挑戰，比方說服務重用。關鍵原因之一是暴露企業服務給新應用背后的復雜性。SOA中理論上服務一般都是可重用的。但實際上往往最終還是有大量的組件與組件之間的硬連接集成，3Scale的CEO Steven Willmott說。
與此同時，由于允許企業通過采用直接的RESTful接口來利用現有服務，API經濟開始爆發。“API無所不在，”Gartner研究副總裁Paolo Malinverno說：“任何使用云的軟件都使用API。公司開始利用API來進行集成，未來實現新應用的敏捷性也要如此。任何純粹是企業內部的應用也都一樣可以利用這些趨勢。”
API與SOA SOA是一種架構，是建構應用的一種方式，它遍歷不同的職能單元，可以隨處調用，Malinverno說。SOA曾與Web服務協議打過交道，大家把SOA與Web服務關聯在一起，但SOA是一種架構，而Web服務卻是一種API風格。
“大家一般都不愿意談SOA，”
Malinverno解釋道：“他們認為這個東西已經過時，沒有用了。但SOA作為一種架構仍然是充滿活力的。”
Web服務只是搞SOA的一種方式而已。相對于老系統內部做SOA的方式，API的確有一種略微不同的連接，但架構上它們多多少少都是一樣的。
Malinverno補充道：“在IT里面，大家的職業生涯是建立在技術基礎上的。更年輕的人不希望聽Web服務的東西。他們希望聽的是REST。”然而REST也限制了交互的復雜性。在不久的將來API管理工具可以幫助彌補這一鴻溝。
REST如此成功的一個主要原因是容易使用。Web開發者可以去到一個門戶上，接收一個API主鍵然后開始測試。Web服務的過程就要長得多、復雜得多，Malinverno說。
RESTful復雜性需求
從長遠看，當企業想給API交互增加復雜性時REST會顯現出自己的局限性。“REST可實現簡單的交互，像增、刪、讀、改等，”Malinverno說：“你需要更加復雜的交互時，就需要事件。事件需要事件處理器來審視并決定該干什么。”
組織會想辦法實現這些更加復雜的交互，但REST和JSON將顯示出自己的限制。“Web服務也沒有希望做這個的，因為大多數Web服務的規范都定稿了，”
Malinverno認為：“還有更多要做，但大家必須繼續前進。我們必須找到別的協議。”
業務邏輯新考慮 Malinverno指出，記住這一點之后，API管理工具的一個關鍵功能就是在平臺之上定義業務邏輯的能力。在今天，業務邏輯被捆綁進業務流程分區、應用邏輯或SaaS包的云端。REST必須有辦法至少表達其中的部分邏輯并支持它們才行。
Malinverno預計API現象會首先會往擴大范圍發展然后才是提高深度。開發者現在需要的是簡單的交互，但是3年之后將會需要更復雜一點的東西。REST還可以干這活兒，而且可以干得很好。大多數移動的增長以及互聯網上的東西都將是基于REST的。 仍然有許多應用是與業務邏輯糾纏在一起的。比方說，絕大多數的SAP實例都內置有定制化的邏輯。為了將來改變業務邏輯是當前B2B應用的主要問題之一。此外，有時候邏輯并不依賴于業務流程。而是依賴于5年前編寫的東西。
標準化接口
“人們開發API已經有15年的時間了，”
Jitterbit產品副總裁Andrew Leigh說：“現在我們提出了‘API管理’這樣的術語。大家在努力思考怎樣才能開發出高質量的API。”
SOA聚焦的是企業內部的連接，但結果證明它比企業所認為的要復雜，更具挑戰性。SOA的這個問題是因為它更多的是方法論而非一套規則。“我們在審視API對SOA的意義時，總是向內看，”Leigh說：“大家用每一種瘋狂的辦法來開發API。我們有SOAP和Web服務，但大家實現它們的方式與云出現之后的有了根本性的不同。”
像Saleforce、NetSuite及Workday 這些基于云的企業取得的大范圍成功證明了開發部署API的標準化之重要性。企業需要考慮像安全和如何針對不同消費者控制API的曝光這樣的因素。“我們看到的問題是大家如何取出防火墻后面的數據并以安全穩妥的方式暴露給防火墻外面，”Leigh說。
支撐API層
功能全面的API網關，由于有著內置的轉換及協調能力，正迅速被采用來在處理輕量級集成以外提供管理和治理層。SOA Software負責產品營銷的副總裁Sachin Agarwal說：“我們看到API曾要么被放到現有集成工具如ESB或者iPaaS上，要么甚至不斷地直接置放到應用本身之上。”
分層需要有合適的遵守企業治理、風險及合規性需求的基礎設施。Agarwal說，API的曝光需要發布、記錄、安全、監控、分析及治理。這些就是API管理工具提供的能力，并且不斷被放到企業級API之上。
由于這些能力，API管理工具被用來作為集成基礎設施的一部分。在某些需要輕量協調與轉換的集成用戶案例中，API管理層提供了傳統依靠專用適配器的重度的ESB的一種低成本的替代。
API管理正在打破被鎖定在本地系統之內的數據之間的壁壘，令這些數據可以為不斷托管于云端的新的基礎設施和應用所訪問，Agarwal說。有了API管理平臺提供的細顆粒度的控制、監控及分析，消費者就有能力分析使用情況，找出哪個服務被調用得最頻繁，然后再進一步調整業務模式或者基礎設施。
開放新的企業采用模式 隨著企業重新架構并為數字化變革進行準備，Agarwal觀察到四種不同的企業采用模式的出現。
平衡發展與控制 大多數SOA都是以企業受控環境或跨受信任的合作伙伴之間的環境為基礎的。“許多你必須解決的問題，像治理，都通過SOA解決，”Willmott說：“企業架構師要進行的轉變是考慮如何把使用這些服務的app整合到一起。”
一旦企業發布了一套資源給規模大得多的受眾，這些開發者干的事情就無法預測了。Willmott指出：“這看起來似乎是微不足道的變化，但卻非常重要。你需要不同層次的身份和信任。”
比方說，紐約市正利用3ScaleAPI管理平臺為其市民開發移動應用。該平臺讓他們能夠以結構化的方式暴露數據，以便第三方可以開發可利用這些服務的應用。這使得大家可以更容易地找到一種不會給城市帶來開發成本的新的方式去開發應用。“大家能拿到想要的東西，而城市一分錢也不用付出，”Willmott說。
京公網安備 11010502049343號