我看Delicious API，看看下面是創建一個新的書籤操作：Delicious會使用GET請求來創建而不是POST，爲什麼我不應該這樣做？
https://api.del.icio.us/v1/posts/add?&url={URL}&description={description}
看起來他們正在使用GET請求來創建服務器端數據庫的條目，這是我」在其他地方閱讀不應使用GET請求完成，只能使用POST請求。
我正在編寫我自己的API，我認爲讓用戶直接從URL與API進行交互是非常棒的。但是，除非您允許通過GET進行CRUD操作，否則不能這樣做。
那麼，真的是真的在通過GET進行CRUD操作嗎？是否有一個重要的原因，我不應該在我的API中做同樣的事情，或者POST是爲了防止意外調用而被授權進行CRUD。
意外調用是它的一部分;這就是HTTP規範在談到「冪等」方法時的含義。但是你可能會爭辯說，只要URL只被添加一次，無論GET有多少次，Delicious所做的實際上都是冪等的。但更重要的是，GET是safe：
The important distinction here is that the user
did not request the side-effects, so therefore
cannot be held accountable for them.
從界面的設計的角度來看，你想用戶代理進行POST和PUT和DELETE比變得更加困難，或者至少明顯不同，從而使用戶可以依靠這種差異來暗示他們的行爲何時可能導致資源狀態的變化，因爲他們是負責這些變化。使用GET進行更改，即使是冪等性的，也會模糊這一問責制，特別是當廣泛部署prefetchers時。
這取決於你是否遵循REST原則GET是改變事物是被禁止的。因此大多數人會說REST使用POST進行更改。
但是，GET和POST之間是有區別的。根據RFC GET請求總是有後續的RESPONSE。如果你使用POST，你需要遵循重定向後模式。
另一個限制是URL可能具有有限的大小。所以只要你的輸入數據足夠短，GET就會工作。所以美味的API有一個錯誤。您將無法通過GET參數添加每個可能的網址。
所以，我認爲這意味着什麼1）Delicious不嚴格服從HTTP中適當的GET和POST協議，但與提交訂單的東西無關，和2）我應該建立我的API，使其更難以POST比GET。 – 2012-01-10 19:02:24