今天圍觀隔壁前後端對接調試接口，發現一個有趣的url接口定義，/users/getInfoByUserId，看url定義能夠理解是根據用戶id獲取用戶信息，然而小貓熊覺得還是有改進的地方。
標準restful的定義採用/users/{userid}的方式，但是一般對於外部用戶，應該採取token而不是在url中填入userid，否則不滿足安全設計，那麼自然會考慮採用動賓結構的形如getxxxbyxxx的方式。
然而，根據restful的風格約定，並不建議在url中出現動詞。其實我們知道，絕對的restful風格WebAPI接口是很難滿足實際業務需求的，比如同樣對於user資源，編輯基本信息和綁定手機號都是可以歸納到對user資源做patch操作，那麼這時候一個put接口是否就能滿足開發需求呢？是否應該針對各個接口涉及到字段域的修改，分別做if/else或者switch/case的分支處理呢？
往往會在url中增加動詞作爲折中處理，正如香農的信息論中所闡述的，信息量的增加是爲了消除不確定性，如果有限的名詞組合不能精確、無二義性的表述接口定義，那麼就會想到通過增加動詞去修飾接口。
其實，採用/users/me/info，然後配合token，可以以更簡明的方式，表達同樣的接口意義。
於是可以推導一下常規webapi的四種形式和定義模板。
第一，外部用戶，採用資源/me/子資源的方式，請求頭嵌入token，例如/users/me/info。
第二，內部用戶在用戶管理模塊中，採用資源/{userid}/info，請求頭嵌入token。
第三，開放平臺訪問資源，可以採用appid，appkey的方式生成token後訪問資源。
第四，匿名登錄。隨意，但要後臺處理同源接口限制。