是什麼讓Flickr API不是RESTful？

我即將開始爲客戶的網站開發REST API，我一直在做一些研究。我在API的黃金標準上遇到了this useful question。是什麼讓Flickr API不是RESTful？

在閱讀本文之前，我曾想過使用Flickr API作爲參考。然而上述問題這個評論讓我想到了兩次：

The Flickr API is particularly hilarious, for example. It advertises itself as RESTful and yet is nothing of the sort! - NathanE

我是什麼讓Flickr的API不REST風格特別有興趣和什麼影響這些沒有REST風格的元素都有。

來源

2010-02-05 Richard Garside

HTTP動詞的錯誤使用：閃爍在http://api.flickr.com/services/replace/中使用動詞「替換」而不是HTTP PUT。另一個例子：http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value 「方法」應該是HTTP方法之一（在這種情況下爲GET）。
閃爍不正確使用HTTP狀態碼。
驗證是不是RESTful的

來源

2010-02-05 09:46:44 deamon

這是否意味着你不能鑑別一個RESTful API？我的客戶端需要對API的某些部分進行身份驗證。是否需要進行身份驗證意味着您應該將REST全部放在一起？ – 2010-02-05 09:58:05

REST可以用於身份驗證。爲了符合REST原則，認證應該是無狀態的（沒有會話）。常見的身份驗證機制是HTTP基本和摘要式身份驗證和TLS客戶端證書。 – deamon 2010-02-05 10:44:51

使用REST時，驗證信息應與每個請求一起發送，以便每個請求獨立於以前的請求。你想避免的是通過某種形式的會話ID或令牌，服務器使用它來驗證用戶是否先前已通過身份驗證。 – 2010-02-05 14:26:20

這個API將被視爲unRESTful另一個重要原因是，因爲它並沒有使用「超文本」的。超文本只是使用鏈接（和鏈接關係）在應用程序中移動客戶端，而不是要求它們以編程方式「構建」URI。

這不是REST風格：

GET /收集
200 OK

<collection> 
    <item> 
    <id>1</id> 
    </item> 
</collection>

這是REST風格：

GET /收集
200 OK

<collection> 
    <item href="/collection/1" /> 
</collection>

後者的RESTful方法的好處是您的服務器可以將項目資源移動到任何地方 - 例如將其移至/ item/1 - 更改href值，並知道所有客戶端都將管理更改。前一種方法無法做到這一點，因爲服務器無法保證所有客戶端都會承認更改;這是所謂的客戶端/服務器耦合的一部分，在大型分佈式系統中，您的API有很多客戶端，因此您希望將其保持在最低水平 - 這是REST的主要目標。

羅伊菲爾丁指REST的這一部分作爲「超文本約束」，他寫了下面的博客文章吧：

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

來源

2010-02-05 11:04:57 Mike

如果客戶端使用表示來構造url'/ collection/1'，並且檢索的媒體類型沒有明確允許這種URI構造，那麼也許您可以限定第一個選項不是RESTful。 – 2010-02-05 14:44:32

我不會宣傳這種方式設計的媒體類型 – Mike 2010-02-05 15:20:36

是什麼讓Flickr API不是RESTful？

回答

相關問題