Rest消息監控系統的URI設計

Question

我正在處理消息的監控系統。消息處理流水線被以下： 新 - >過程 - >處理 - >移除（歷史）

該系統必須能夠：

• 請求的所有消息，並通過所述唯一標識符
• 修改它們（我的意思是標記作爲處理，標記爲刪除，等等），使用
• 搜索消息字段過濾器（例如，通過消息 所有者搜索）

我無法設計包含名詞的RESTful URIs，而不是這個動詞。我很難在這個系統中找出正確的資源。

最簡單的方法是去與URI的像

host/messages/new 
host/messages/processing 
host/messages/processed 
host/messages/removed 

但它不是休息，因爲 - 這仍然是相同的消息，但不同的字段值，他們不是新的實體 - 我用用於識別狀態的動詞，而不是資源

所以問題是如何在這裏應用REST設計？ 我幾乎不能想象系統處理對象狀態監視的REST設計。

我會感謝您對此主題的想法和建議。

Answer 1

首先，RESTful系統不應該花費很多精力來設計URI，而應該專注於媒體類型的創建並使用URI的關係名稱，以便客戶端可以查找其中的含義媒體類型。客戶端本身不驗證或解釋URI，因此並不關心URI的外觀，它只是根據關係名稱根據媒體類型中概述的語義調用URI。

這具有將資源綁定到關係名稱而不是具體URI的優點。如果服務器更改資源的位置，則使用關係名稱而不是URI本身的客戶端仍然能夠處理請求，而不管URI指向的位置如何。

對於您的具體示例，您有一個消息資源和屬於該資源的某個狀態。你如何設計這種關係取決於你。如果您希望消息的實際有效負載不受影響，您可以將狀態信息放在標題中，這些標題基本上是返回文檔的元數據，或者將它們定義在相應消息的子資源中。您也可以使用（或定義您自己的）媒體類型，支持類似於HAL的嵌入資源，允許嵌入屬於某個資源的其他數據。

包含其當前狀態的消息的類HAL表示可能看起來像下面的示例。但請注意，這種表示不是基於實際的媒體類型，也不是完整的。它應該只是想象你可以在你的方法中使用的概念。

{ 
    "_links": { 
     "self": { 
      "href": "/api/messages/1234", 
      "title": "Get the latest version of this message" 
     }, 
     "states": { 
      "href": "/api/messages/1234/states", 
      "title": "List states the message has been in in chronological order" 
     }, 
     "find": { 
      "href": "/api/messages{?id,sender,receiver,state}", 
      "templated": true, 
      "title": "Find messages" 
     }, 
     "markAsProcessed": { 
      "href": "/api/messages/1234/states", 
      "title": "Mark message as processed", 
      "type": "application/vnd.your-comp.message-state-update+hal+json" 
     }, 
     ... 
    }, 
    "sender": "User1", 
    "receiver": "User2", 
    ... 
    "_embedded": { 
     "current_status": { 
      "_links": { 
       "self": { 
        "href": "/api/messages/1234/states/new" 
       } 
      } 
      "type": "new", 
      "timestamp": "2017-10-21'T'22:25:00Z", 
      ... 
     } 
    } 
} 

在HTML數據要發送到的服務器通常在表現公式（<form>...</form>）輸入。 HAL沒有明確定義這樣的結構。在擴展媒體類型時，現在可以在媒體類型中定義HTML表單的對應項，或者定義客戶端應該如何處理特定關係名稱的規則集。

在這個簡單的例子中，客戶必須根據數據交換的媒體類型來扣除如何處理某個鏈接關係，如markAsProcessed。它可以定義調用markAsProcessed鏈接關係的請求應該向服務器發送包含給定消息的最新狀態信息的PUT請求。在這種情況下，明確列出發給服務器的請求應該與媒體類型application/vnd.your-comp.message-state-update+hal+json兼容，它定義了服務器期望的有效載荷的實際語法和語義。

HAL (draft version 08)提供了一些您可以在鏈接關係名稱中使用的其他字段。如果這不足以滿足您的需求，則必須通過添加指定的PUT,PATCH或鏈接的新鏈接來擴展媒體類型。這也需要在新的或擴展的媒體類型中定義，並且可能由其他客戶端使用，以便允許其他供應商將這種媒體類型實現到其框架中，從而允許其他客戶端使用這個媒體類型。

但是，在創建新介質類型之前，如果有類似的東西已經可用，您可以使用或進一步擴展，則應該使用check the registered media types。

請注意，他只是一個建議。由於REST不是一種協議，而只是一種架構風格，如果遵循正確的話，它允許分佈式系統中的客戶端與服務器API分離。如果您爲自己的Web API維護自己的客戶端，那麼當然可以遵循自己的接受程序，不過您應該將您的服務標記爲簡單的Web API並進一步避免「營銷術語」REST。