日前，subbu allamaraju在博文中談到當前rest api使用過程中的一些問題，並提出了一些改進辦法。
allamaraju認為，人們在使用rest api時面臨的幾個主要問題是：
介面不匹配：因為api是由其提供者建立的，所以往往體現建立者的視角——幾乎所有api的最大共同特徵都是最大化其使用和重用。這一特點往往導致api的粒度過細，這樣每個消費者就可以呼叫api集合的任何子集，並且可按照任何次序進行呼叫。
在此過程中， [提供者]必定要犧牲消費者的那些特殊需求，而且盡量堅持於那些通性徵。這就導致了消費者需求和api**之間的不匹配。編寫客戶端**比較慢，繁瑣而且經常重複：使用細粒度api產生多次呼叫，然後將所有返回結果聚合起來。
如果沒有乙個處理這些api的sdk，你需要花很長時間去處理2*n次呼叫以及其響應（譯註：allamaraju在博文中舉了 乙個示例，該示例的客戶需求是查詢一組產品的id、詳細資訊以及相應的使用者評價，在該場景中首先需要先做一次查詢，得到n個產品id，然後對每個id做兩 次呼叫，分別是查詢詳細資訊和查詢使用者評價，如總共的呼叫次數為2*n）。除此之外，每次api呼叫時客戶端程式還需要構建請求和解析響應。
等待api提供者的功能增強往往耽誤時間：因為api提供者要支撐許多消費者，並且按照自己的工作計畫行事，該計畫往往與消費者的計畫不同，特殊的消費者需求很難與提供者的計畫同步。此外，因為提供者通常要衡量api的重用，所以很難為某個特定的消費者單獨提供乙個api……
api呼叫常常很繁瑣：繁瑣的客戶端指的是為了完成一次功能需要發出多次http請求，從而導致嚴重的效能下降及網路超載。不論從效能還是從網路利用率的角度看，直觀的感覺是使用粗粒度的api會更好。
restful api的一致性沒有我們相像的那麼重要：理想情況下，保持api實現之間的一致性固然很好，但是allamaraju認為，rest api的最重要的特性是互操作性：
我寧可把時間花在互操作性上，而不是一致性上。allamaraju在博文結尾如此總結：
客戶端的主要挑戰是對發起請求（fork）和合併響應（join）的聚合、並行處理和編排。那麼，如何解決這一問題呢？allamaraju提到：
……在ebay，我的團隊正在建設乙個新平台，通過它可簡化上述案例：allamaraju不是唯一提到此類平台的人，早在今年舊金山舉行的qcon上，來自netflix的daniel jacobson就介紹過乙個正在實現中的相似解決方案。
allamaraju和jacobson提出的解決方案極有意義，但又不禁讓人想問：它和esb有何區別？而esb卻好像被指為致使soa失敗的主要原因之一？難道問題不在於esb而在於沒有用好它？或者它一直是很好的模式，而現在又得到第二次機會？
筆記 REST API 設計
evernote export body,td 04 07 2015 saturday 15 50 04 07 2015 saturday 17 48 liker.xu head 安全 冪等 options 安全 冪等 put 寫操作 更新或新增資源 冪等，多次插入或者更新同乙份資料，不安全 pos...
rest api入門介紹
隨著 rest 成為大多數 web 和 mobile 應用的預設選擇，勢必要對它的基本原理有所了解。在它提出十多年後的今天，rest 已經成為最重要的 web 應用技術之一。隨著所有技術朝著 api 方向發展，它的重要性有可能持續快速地增長。每門主要程式語言現在已經包含構建 restful web ...
REST API基礎介紹
1 介面中盡量使用名詞 2 使用post請求資源 3 delete請求刪除資源 eg.get notes id 獲取某個指定id的筆記資訊 1 rest resource representational state transfer 資源在網路傳輸中 以某種 表現形式 進行 狀態轉移 ps 網際網...