在REST API中處理標誌和屬性的選項有哪些？

Question

假設您在REST API中有一個複雜的資源。您在此資源上有幾個一對多標誌和屬性（即用戶可能已給予該資源的評分爲1至5或用戶可能已'喜歡'該資源或將其標記爲垃圾郵件或將其忽略或引起一些其他國家將被設置）。

對於以資源爲中心的體系結構來表示這一點的最佳方式提出了一些建議，但到目前爲止，沒有一個能夠讓我真正感到高興。所以讓我們來分析一下這個問題。你發現哪些變體最容易理解？我們沒有想到哪些變體？假設一個基於OAuth的API和這裏的所有內容都是在當前授權用戶的上下文中完成的。

• 布爾標誌

  • 變型1：

     
    GET /resource/{id}/muted 
    POST /resource/{id}/muted BODY:true 
    POST /resource/{id}/muted BODY:false 
    

  • 變體2：

     
    GET /resource/{id}/muted 
    PUT /resource/{id}/muted BODY:true 
    DELETE /resource/{id}/muted 
    

  • 變體3：

     
    GET /resource/{id}/attributes 
    POST /resource/{id}/attributes BODY:muted=true 
    POST /resource/{id}/attributes BODY:muted=false 
    

  • 變體4：

     
    GET /resource/{id}/muted 
    POST /resource/{id}/mute 
    POST /resource/{id}/unmute 
    

• 屬性

  • 變體1

     
    GET /resource/{id}/rating 
    POST /resource/{id}/rating BODY:4 
    

  • 變體2：

     
    GET /resource/{id}/rating 
    PUT /resource/{id}/rating BODY:4 
    DELETE /resource/{id}/rating 
    

  • 變3：

     
    GET /resource/{id}/attributes 
    POST /resource/{id}/attributes BODY:rating=4 
    POST /resource/{id}/attributes BODY:rating= 
    

的思考？建議？其他API如何處理？你是怎麼處理它的？您是否發現這樣的設計問題對開發人員的幸福感或API的易用性有重大影響？

Answer 1

Roy's dissertation來自：

一個統一的接口降低效率，因爲信息是在標準化的形式，而不是一個，其是特定於應用程序的需求轉移。REST接口的設計是高效的爲大粒超媒體數據傳輸

所以你需要一個變種5，其同時適用於標誌和其他屬性：

GET /resource/{id}/ BODY:{muted: false, like: false, rating: 2, ignored: true} 
POST /resource/{id}/ BODY:{muted: true, like: false, rating: 2, ignored: true} 
POST /resource/{id}/ BODY:{muted: false, like: false, rating: 2, ignored: true} 

一個大原因是，大多數的一個RESTful HTTP應用程序的效率來自緩存，當它的工件儘可能大時，以及儘可能少的標識符可訪問數據時，該應用程序效果最佳。如果您在/resource/{id}/和/resource/{id}/muted處公開「靜音」標誌，則表明您有緩存失效問題。如果您僅在/resource/{id}/處公開它，那麼您不會。

如果你正在設計一個應用程序，通過小型有效載荷的目的是爲效率，那麼你就無法從種糧大戶的緩存中受益，剩下的建築風格是不是適合你的應用程序。 HTTP可能不是，但我可以理解某人在今天的市場中會如何被卡住。

Answer 2

我喜歡變3，如果我可以一次提供了一堆 - 否則，我很冷漠1和3

而且，使用DELETE絕對之間什麼都沒有。