純 rest 要用名詞, 所以要改寫成 /user/{id}/approval。
我是有看到用動詞的例子：
- Best practices for RESTful web service design1：第 9 頁提到 Use nouns for non-resource actions，但是例子卻是給 convert, calculate (動詞)？
- RESTful 與 Rails2：這裡有提到
/bookmarks/:id/edit(edit 也是動詞)
要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。
說的也是 ...
而且用
PATCH就對了嗎？approve user 這個動作有可能改到三個 Table 以上，不一定是只改user.approved這個 boolean flag 而已啊。
我只是覺得 approve 這個動作應該只是在 update 資料，所以用 PATCH 比較合適 ...
不過改三個 Table 有可能代表了同時修改三個資源，這部份 REST 目前也沒有規範到 ...
就像您說的那樣，最後會是 REST 和 RPC 混用吧
純 rest 要用名詞, 所以要改寫成 /user/{id}/approval。
要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。
而且用 PATCH 就對了嗎？approve user 這個動作有可能改到三個 Table 以上，不一定是只改 user.approved 這個 boolean flag 而已啊。
API 版號應該出現在 URI 中還是 HTTP header 中？以 REST API Versioning 的描述兩種皆可，但看完論文後哪種較好呢？
- 我覺得 API 版號應該出現在 URI 中，因為這樣可以保證 client 端不會 call 錯版本 ... (雖然這樣的 URI 有點不好看 ...)
- 若是用 parameter 或 header 來指定 API 版號，就有 client 端給錯資料而 call 錯版本的風險 (當然如果 client 端是可信賴的就沒差)
我最後都是混用。只有簡單的 CRUD 才會用 REST，其他很難用 resource 表達的通通用動詞 + POST (就是 RPC)
不過 url 都會是小寫英文 和 - 就是了。然後就算是 RPC ， url 也會傾向用 /approve/user/{id} 而不是 /approveUser?id={id}
Java8 應該會是有史以來會被維護最久的版本吧，一堆人會卡在這。
ubuntu 18.04 本身就是裝 openjdk8 ，所以最少會被 canonical 維護五年
在做投影片時剛好跟上這個話題 What does LTS mean for OpenJDK? 1 ，看內容就像現在 jdk7u2 ， changelog4 一樣，會有組織出來 patch/backport，所以問題就剩下誰來包？至少 AdoptOpenJDK3 會包，所以不用太擔心沒有免費的 LTS。