RESTful枚舉。字符串或ID？

我應該將它們公開爲本地化字符串還是純整數？

我倚向是在服務端容易轉換整數，但在這種情況下，客戶端需要從什麼地方抓的本地化字符串列表，以便知道是什麼意思枚舉。我只是爲了什麼而創造額外的步驟？

好像有一點信息，我可以找到哪些是常用的RESTful API中完成的。

編輯：

好的。假設我正在寫一個存儲有關人們寵物信息的網站。我可以有一個AnimalType枚舉

0 Dog 
1 Cat 
2 Rabbit 
etc.

當人們抓住一個特定的寵物資源，說/pets/1，我可以向動物提供類型有意義的本地化字符串，或者只是提供了編號，並強迫他們做另一個查找通過/pets/types資源。

或者我應該提供嗎？

來源

2012-12-14 GazTheDestroyer

我想你應該考慮一致的RESTful API你想暴露給你的客戶。

你自己在你的代碼中使用枚舉是你的實現細節。 Wheter你的客戶將在他的實現中使用枚舉，你既不知道也不應該打擾你，因爲這只是不同的抽象級別。

API設計優先，實施如下。

如果你提供你想要使用這些枚舉我可以給更直接的答案返回給客戶什麼樣的信息多一點洞察力。

現在，我猜如果整數ID和字符串描述與描述信息或狀態相關，您希望返回調用您的RESTful資源，那麼你應該返回它們都包裝在json或xml文檔中。

來源

2012-12-15 14:51:26

已編輯我的問題，歡呼聲。 – GazTheDestroyer

我會說，作爲對/ pets/{petId}的迴應，您應該提供有關資源的完整信息，以便您的案例，本地化字符串和ID。你也可以在/ pets下提供一個收集資源，這個資源可以返回一個完整的寵物資源表示集合，或者只是部分表示（也許是寵物id）和個人寵物資源（http：// .../pets/{petId}）或只是一個網址集合。 –

如果意圖是讓API消費者以編程方式使用這些值（即基於它們作出決定），我會使用UNlocalized字符串（並確保它們有充分的文檔記錄和穩定性）。枚舉值沒有在本地開發框架中進行本地化，開發人員也習慣於處理這個問題，不知道爲什麼web API會有所不同。

如果意圖是讓API消費者向用戶顯示這些值，我會使用本地化的字符串。

如果意圖能夠做到這一點，我會使用UNlocalized字符串（ID），但考慮提供一個單獨的API端點/資源（甚至脫機文檔）以將這些ID映射到本地化字符串。

如果由於某種原因你真的關心消息大小（例如，你在一條消息中有數以千計的這些東西，而且是一個移動場景），那麼只有考慮帶有數字ID。

來源

2012-12-17 05:02:09

RESTful枚舉。字符串或ID？

回答

相關問題