關於rest api更新資源的討論：
當更新乙個物件的時候，是否要將完整object全部資訊重新提交到伺服器？還是只提交部分內容？
好處是
一種是部分提交的方案
弊端
事實上查閱資料後，發現這是乙個架構設計的問題。
一切開端於rest api的設計原則。
根據rest api的設計哲學，每個api需要有以下幾個性質：
1. 伺服器-客戶端原則
- 在整個應用中，需要將客戶端與伺服器分開，兩者之間盡量解耦合，都可以分開演進
2. 無狀態
- 客戶端的狀態不會在服務端儲存。每個session的資訊只在客戶端儲存。
3. 可快取
- 同樣的請求應該有同樣的返回，使得請求可快取。
4. 分層
- 客戶端無法分辨自己是否直接連線到伺服器或者是中間層。這個性質可以進一步增強可擴充套件性。
5. 統一的介面設計
- 這個是rest介面設計的核心。分為以下幾個小原則
1. 識別資源
- 資源通過請求進行識別。識別後的資源會在服務端進行轉換格式，返回到客戶端。返回的格式與資料本身無關。
2. 通過資源的表達來操作資源
- 客戶端需要儲存完整的資源，以及必要的元資訊（metadata），使得這些資訊足夠對資源進行修改或刪除。
3. 自解釋的訊息
- 每個訊息需要包含足夠的資訊來決定如何處理這個訊息。例如在指定parser的時候需要使用internet media type來指定。
4. hateoas
- 字面意思是，超**作為應用狀態轉移的引擎
- 從最開始的一共請求開始，每次返回的請求能夠告訴客戶端，服務端還有哪些資源提供。有時可以返回帶有超連結的文字。
- 客戶端不需要根據服務端的資料結構進行任何定製
這些原則很多是過於嚴苛的。在實際操作中如果嚴格遵循，會給架構設計帶來很大的約束。
這裡我們只討論乙個細節，就是前端在修改內容的時候，是否需要上傳完整的資料？
原始的rest api中，只提供get，put，post，delete四種操作。
get：獲取資源列表或單個資源。這是一種nullipotent的操作，即，操作進行多次之後，等於沒有進行。對於任何正整數n，x^n = 1.
put: 將指定的資源進行替換。如果作用在collection上，則替換整個collection。這是乙個冪等操作，即操作多次之後，等於操作一次，而且每次操作的結果是相同的。對於任何正整數n，x^n = x.
post：一般只作用於collection上。在這個collection中新建一條記錄。
delete：刪除對應記錄或collection。
這四種操作，除了post，都有很好的性質。但針對如何對乙個物件的部分字段進行更新，則一直有各種爭論。
後來在2023年的時候，http協議中增加了乙個操作：patch，
此時rest api也使用這個新的操作來進行資源的部分更新。
但是，這個patch操作有許多值得注意的地方，乙個是，這個操作不冪等，乙個是，在進行patch操作的時候，
需要以原子操作的形式來進行，而不能同時指定多個更新字段。
例如，在更新資源時，需要指定是增加，還是更新某個字段。
patch /users
[
]
patch /users/123
[
]
patch 為何不冪等呢？
有兩個解釋，乙個是，在兩次patch請求之間，如果對應資源有改變，那麼兩次patch請求造成的結果不同，
返回的object也不同。
另乙個解釋是，當資源模型中有乙個列表時，如果多次執行 add 操作，那麼這個列表幾次操作後得到的結果也不同。
所以，我的看法是，在盡量多的地方使用put，對完整資源進行更新，在必要時使用patch，指定原子級別操作來進行部分更新。
知乎改版使用restapi後模擬登入
首先是抓包分析,知乎的登入介面變為了 找下這個介面的引數,懶的乙個個複製了,瀏覽器裡抓來就貼這裡了,各位將就看下 signature 引數僅僅就是對一堆變數進行hmac sha1 hash得到的乙個值，對應的幾個引數，clientid，granttype，source都是不變的，唯一有變化的是tim...
如何使用 Debian backports 更新源
backport的含義是 向後移植 就是將軟體新版本的某些功能移植到舊版本上來,這就稱為backport。debian向來以穩定性著稱，所以就存在乙個問題，官方源分發的軟體版本比軟體本身的版本總是要慢不少，所以就有了 backports 源。backports 主要從 testing 源，部分安全更...
yii where or該如何使用
今天除錯yii專案的時候，遇到乙個奇葩的事兒，在除錯 where or 查詢的時候 除錯語句是這樣 str static find where or username username,mobile account echo echo str createcommand getrawsql 很明顯，...