我正在努力確定如何設計靜態URL。我全力以赴地使用帶有名詞而不是動詞的URL來解決這個問題。我們正在創建一項服務以實現財務計算器。計算器帶有一系列參數，我們將通過CSV文件上傳這些參數。用例將涉及：上載新參數獲取最新參數獲取給定營業日期的參數激活一組參數驗證一組參數我收集的寧靜方法是使用以下類型的URL：/parameters/parameters/12-23-2009您可以使用以下方法實現前三個用例：POST，您將參數文件包含在發布請求中GET第一個URL獲取第二個URL但是，如何在沒有動詞的情況下使用第4和第5個用例呢？您不需要以下網址：/parameters/ID/activate/parameters/ID/validate??
3 回答
大話西游666
TA貢獻1817條經驗 獲得超14個贊
也許像這樣：
PUT /parameters/activation HTTP/1.1
Content-Type: application/json; encoding=UTF-8
Content-Length: 18
{ "active": true }
慕桂英3389331
TA貢獻2036條經驗 獲得超8個贊
良好URI設計的一般原則：
不要使用查詢參數來更改狀態
如果可以，請不要使用大小寫混合的路徑；小寫是最好的
不要在URI中使用特定于實現的擴展名（.php，.py，.pl等）
不要隨便使用URI 進入RPC
不要限制你的URI的空間盡可能地
路徑段要盡量短
做不是選
/resource或/resource/; 從您不使用的位置創建301重定向做一個資源的子選擇使用查詢參數; 即分頁，搜索查詢
DO移動的東西出來的URI的，應該是在HTTP報頭或身體
（注意：我沒有說“ RESTful URI設計”； URI在REST中本質上是不透明的。）
HTTP方法選擇的一般原則：
永遠不要使用GET更改狀態；這是讓Googlebot破壞您一天的好方法
除非要更新整個資源，否則不要使用PUT
除非您也可以合法地對同一URI執行GET，否則請勿使用PUT
不要使用POST來檢索壽命長或可能合理緩存的信息
不執行不操作冪等與PUT
不要使用GET為盡可能
做優先投入使用POST有疑問時
不要使用文章時，你要做的東西，感覺RPC樣
不要使用PUT對資源類，較大或分層
請優先使用刪除博文，刪除資源
請勿將GET用于計算之類的事情，除非您的輸入很大，在這種情況下，請使用POST
使用HTTP進行Web服務設計的一般原則：
不要將元數據放在應放在標題中的響應主體中
請勿將元數據放在單獨的資源中，除非包含元數據會造成大量開銷
請使用適當的狀態碼
201 Created創建資源后；發送響應時資源必須存在202 Accepted成功執行操作或異步創建資源后400 Bad Request當某人對明顯偽造的數據進行操作時；對于您的應用程序，這可能是驗證錯誤；通常為未捕獲的異常保留500401 Unauthorized當有人在不提供必要Authorization標頭的情況下訪問您的API 時，或其中的憑據Authorization無效時；如果您不希望通過Authorization標頭獲得憑據，請不要使用此響應代碼。403 Forbidden當有人以惡意方式或未經授權的方式訪問您的API時405 Method Not Allowed當某人使用POST時應該使用PUT等413 Request Entity Too Large當某人試圖向您發送不可接受的大文件時418 I'm a teapot嘗試用茶壺沖泡咖啡時不要使用緩存頭時，您可以
ETag當您可以輕松地將資源減少為哈希值時，標頭就很好Last-Modified應該向您表明，保持資源更新的時間戳記是一個好主意Cache-Control并且Expires應該被賦予明智的價值做一切你能兌現在請求緩存頭（
If-None-Modified，If-Modified-Since）請在合理的情況下使用重定向，但是對于Web服務來說，重定向應該很少
關于您的特定問題，POST應該用于＃4和＃5。這些操作屬于上面的“類似于RPC”的準則。對于＃5，請記住POST不一定必須使用Content-Type: application/x-www-form-urlencoded。這很容易就是JSON或CSV負載。
開滿天機
TA貢獻1786條經驗 獲得超13個贊
每當您需要新的動詞時，請考慮將其轉換為名詞。例如，將“激活”轉換為“激活”，將“驗證”轉換為“驗證”。
但是僅從您編寫的內容來看，我會說您的應用程序存在更大的問題。
每當提出一種稱為“參數”的資源時，它都應該在每個項目團隊成員的腦海中發出危險信號?！皡怠睂嶋H上可以應用于任何資源；還不夠具體。
“參數”到底代表什么？可能有很多不同的事物，每個事物都應該有一個專用于它的資源。
另一種解決方法-與最終用戶（可能對編程了解甚少的最終用戶）討論應用程序時，他們自己反復使用哪些詞？
這些是您應該在周圍設計應用程序的詞。
如果您尚未與潛在用戶進行這種轉換，請立即停止一切操作，除非您這樣做，否則不要再編寫其他代碼！只有這樣，您的團隊才能了解需要構建什么。
我對金融軟件一無所知，但是如果我不得不猜測，我會說某些資源可能會使用“ Report”，“ Payment”，“ Transfer”和“ Currency”之類的名稱。
關于軟件設計過程的這一部分，有很多不錯的書。我可以推薦的兩個是域驅動設計和分析模式。
- 3 回答
- 0 關注
- 599 瀏覽
添加回答
舉報
0/150
提交
取消