我剛剛讀完Restful Web Services和Nobody Understands REST or HTTP，並試圖用RESTful設計來設計API。爲什麼有人會在URI中用'API'設計一個RESTful API？
我注意到在API URI設計的幾個模式：
http://api.example.com/users
http://example.com/api/users
http://example.com/users
假設這些設計正確使用Accept和Content-type頭爲XHTML，JSON，或任何格式之間content negotiations。
這些URI是否爲純 REST式實現與隱式內容協商？
我的想法是，通過顯式使用的URI API是爲了讓客戶將期望的數據格式本身不是人賞心悅目的超媒體可以更容易地消耗不明確設置的Accept頭。換句話說，API暗示您期望JSON或XML而不是XHTML。
這是一個在邏輯上在服務器端分離資源表示 的問題嗎？
的唯一理由，我可以想出爲什麼有人會設計他們的URI與API子域是關閉基於我的假設，這是一個縮放技術，因爲，它應該在一個多路由請求負載更容易分層服務器基礎架構。也許情況下反向代理正在剝離標題？我不知道。處理不同表示的不同服務器？
也許子域僅用於外部使用者，以便服務器避免內部使用的開銷。限速？
我錯過了一個觀點嗎？
我提出的設計將嘗試通過設置適當的報頭，適當使用HTTP動詞和時尚，我覺得包括在URI「API」是多餘的代表資源遵循REST風格的做法。
爲什麼有人會在URI中用'API'設計一個RESTful API？
或者他們可以嗎？也許我不明白這個設計的問題是它沒關係，只要它遵循一些可能不會導致RESTful API實現的規範組合但並不重要？ 皮膚鍵盤貓有多種方法。 HATEOAS有關聯的？
更新：雖然研究這個題目我都來，這是很重要的考慮從REST的想法，但不把它當作一種宗教的結論。因此，在URI中是否有'api'更像是一個設計決定，而不是一個堅定的規則。如果你計劃公開你的網站的API，使用api子域來幫助處理應用程序的邏輯是一個好主意。我希望有人會貢獻自己的洞見，讓別人學習。