Problem
幾年前聽到同事說:「另一個部門的XXX說我們的REST API都沒有動詞,這樣是對的嗎?」於是我們就直接把Best Practice丟給那位同事。當時做REST API只是因為別人有而要做,而不是為了某個Context而選擇REST;後來我就思考著一件事情: 「RPC-Style與REST API比起來,到底有哪些好處?」於是我花了些時間去找尋與整理資料。首先我會先說明這裡指的RPC-style API是什麼,接著我會透過Richardson Maturity Model(RMM)說明它們兩者的差異。這是我目前認為最好的比較方式。
RPC-style API
網路上許多比較,大都是針對RPC與REST;我所說的RPC-style API是基於HTTP,主要有兩點特徵:
- 基於operation所設計出來的API,因此URI通常像/createAccount、/getAccounts、/deleteAccount與/updateAccount。
- HTTP method只會使用GET與POST,GET使用在取得資料,POST使用在新增、修改、刪除資料。
基於RMM的比較
RMM不是定義REST達到了什麼級別,而是幫助我們層層思考的一種方式(參考)。Roy Fielding 2008年的某篇文章,給了RESTful API很嚴格的限制,也代表著Level 3只是Restful的前置條件。由於RPC-style API屬於Level 0,因此我認為用RMM來說明REST API比RPC-style好在哪裡是再適合不過的:
Level 1 - Resource
Server
Client
Level 2 - HTTP Verb
Level 3 - Hypermedia Controls
"links": [ { "rel": "search", "method": "POST", "href": "https://192.168.0.1/api/search" }, { "rel": "get_accounts", "method": "GET", "href": "https://192.168.0.2/api/accounts" } ]
也因此resource名稱對於client來說,在runtime時就不是這麼重要了,重要的是rel的名稱;這應該是Roy Fielding在這篇文章說以下內容的原因吧:
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server).
而API evolution也因為透過link ref與Resource互動的特性,使得你不用害怕改Resource的名稱。
Summary
我只針對REST比RPC-style好在哪裡做說明,這不代表著REST就一定比RPC-style好。下圖是我以前念書時候的一個作業,雖然server使用物件導向去設計model,但與client的溝通我還是選擇了RPC-style的方式:
假如是一個不是很大的專案,而且client只有我自己,我還是很有可能選擇使用這樣的方式,因為簡單且省時。重點是要使用甚麼方式,是要看當時所面對的Context,這也讓我思考hypermedia的特性到底對我們有沒有用。
這裡補充別人針對hypermedia API統計的資料給大家參考:
- 2014年CA Technologies從180個API供應商中,得知有26.3%有實作hypermedia API,有28%要支援此功能。(link)
- 2015年Akana舉辦一個線上研討會,從76人中得知有16%的人正在使用hypermedia API,而40%的人計畫要使用。(link)
以上是目前的心得分享。
Reference
- Do you really know why you prefer REST over RPC?
- REST APIs must be hypertext-driven
- Richardson Maturity Model
- What are the advantages of REST over a more RPC style?
- 淺談 REST 軟體架構風格 (Part.I) - 從了解 REST 到設計 RESTful!
- 什麼是REST跟RESTful?
- Hypermedia and API evolution
- API設計如龍生九子,Tunneling、Hypermedia等更受開發者青睞
- The Movement Towards Hypermedia APIs – Is it Happening?
留言
張貼留言