REST資源相關數據

我創建了一個REST API，我認爲我被困在一個RESTful問題中。REST資源相關數據

它與下列問題有關：

我有一個資源被稱爲「個案」。案例也有相關的數據，如用戶和消息。問題是我想從案例中獲取相關的查詢用戶和消息數據，但我不確定使用URI設計。也有不同種類的相關/計算數據。應該使用這些相關數據來創建數據可視化。

我如何獲得案件/用戶/消息是，雖然REST風格：

http://example.com/cases (and with id for a single case) 
http://example.com/cases/{id}/users (same idea as above) 
http://example.com/cases/{id}/messages (same idea as above)

我的第一個想法創造相關資源是（我認爲URI看起來錯誤，它可能變得有點RPC）：

相關數據1：

http://example.com/cases/{id}/analysis/messages-network-traffic 

{ 
    "sender": "an user jack", 
    "receiver": "an user steph", 
    "amount_messages": 51 
}, 
{ 
    "sender": "an user test", 
    "receiver": "an user test4", 
    "amount_messages": 3 
} 
...

相關數據2：

http://example.com/cases/{id}/analysis/messages-timeline?receiver=testuser1&sender=testuser2 
{ 
    "amount_messages": 24, 
    "timestamp": 1387321576 
}, 
{ 
    "amount_messages": 50, 
    "timestamp": 1387321576 
} 
...

這些URI設計是否正確？（我認爲它是RPC的一種），或者我該怎麼做？因爲我沒有看到任何理由來創建像相關問題那樣的報表資源。數據只是對現有資源的計算。

預先感謝您。

來源

2013-12-17 A. Ly

只因爲你可以提供一個實現並不意味着這樣做是有道理的。例如，在http://example.com/cases上執行PUT可能沒有意義。您可以將其替換爲http://example.com/cases/1或類似的東西。一個特定的例子。同樣，在http://example.com/cases/1上執行POST也可能沒有意義。您可以使用REST的語法來決定應用程序的語義。

我沒有看到你的REST設計有什麼問題 - 只要端點以'聲明式'方式命名，那麼它就可以。如果他們有一些'程序性'的名字，如：http://example.com/cases/goDoSomething，這將是一個值得關注的原因。

請記住，您的REST設計是您的客戶用來與您的服務進行交談的「語言」，因此請設計該語言以便溝通是聲明性的，並且適合於手頭的任務。爲用戶設計，而不是爲了後端的方便。

來源

2013-12-17 23:30:46

你這些網址似乎細：

http://example.com/cases（和ID爲單個的情況下）

http://example.com/cases/ {ID} /用戶（如上述同樣的想法）

http://example.com/cases/ {ID} /消息（與上面相同的想法）

根據您的相關數據以及如何查詢它們，我會建議首先你應該決定返回數據結構，考慮到在這兩種情況下你都要返回「消息」（雖然包含有些不同的數據）。我會做的是，我想有一個共同的JSON結構兩個相關資源的URL的東西沿着

{「發件人」的臺詞：「一個用戶測試」，

「接收器」：「一個用戶TEST4" ，

「amount_messages」：3，

「時間戳」：12312421424}

我的資源URL看起來有點像這樣：

GET http://example.com/cases/ {ID} /消息

GET http://example.com/cases/ {ID} /消息？接收機= testuser1 &發件人= testuser2

我不明白，對於「/的原因分析「在網址中。這有點多餘（除非有特定的原因）。準備使用您的apis的客戶希望返回數據是通用的，尤其是當他們試圖在同一資源上執行過濾查詢時。在你的情況下，我們要麼列出「消息流量」（我會打電話列出「所有消息」）或列出「消息流量」其中發件人是FOO和接收器是BAR（我將過濾「所有消息」數據發送者和接收者的信息。

保持返回的數據模型一致幫助客戶開發人員生成的POJO（在Java中的土地）和/或一致的數據模型上的一面。

我希望這可以幫助！祝你好運！

來源

2013-12-18 01:49:06 shahshi15

我的例子是關於消息的，但它可以返回一個「case」的相關資源的所有相關計算數據。所有這些計算的數據結果都儘可能通用返回，但結果旨在創建分析工具（如圖形和內容）。對於每個圖形式，他們需要另一個結果。這就是爲什麼我通過以下方式將每個案例分開： _/analysis/a-graph-data-result-style_ –

這就是要點，你不應該這樣做。正如史蒂夫上面提到的，網址不應該是聲明性的。如果你想讓你的返回類型與圖表風格相關，你可以使用類似的方式： GET http://example.com/analysis/{graph-style}/cases/{id}/messages?receiver= testuser1＆sender = testuser2 查看urls客戶端可以很容易地確定數據模型可能不會改變（這裏的數據格式總是「消息」的數據格式），但數據本身會根據他們要求的圖形樣式數據。 – shahshi15

但在大多數情況下，作爲服務提供者，您不應該擔心客戶端正在實施什麼樣的圖表風格。 Facebook/Google可能有一個由客戶開發的巨大應用程序，每個應用程序都執行它們自己的一組圖形（取決於用戶的用途）。如果他們開始爲每個客戶端提供圖形樣式自定義數據，那麼對於任何服務提供商來說都沒有意義。 – shahshi15

我知道你已經在這裏接受了一個答案，但我覺得這兩個答案都錯過了這個商標

爲你的問題設計一個RESTful解決方案沒有什麼與你的URL看起來有關，一切與提供關係鏈接作爲表示本身的一部分。您需要使用允許您表達這些鏈接關係的媒體類型。 HTML不會，但XML和JSON本身不是。我個人最喜歡的是HAL over JSON。

這是你的例子可能看起來像使用HAL超過JSON：

請求：

GET /cases/1 HTTP/1.1 
Host: example.com

響應：

HTTP/1.1 200 OK 
Content-Type: application/hal+json;profile=vnd/com.example-v1 

{ 
    _links: { 
    "self": { 
     href: "/cases/1" 
    }, 
    "users": { 
     href: "/cases/1/users" 
    }, 
    "newest_user": { 
     href: "https://stackoverflow.com/users/371629" 
    }, 
    "messages": { 
     href: "/cases/1/messages" 
    } 
    }, 
    "case-name": "Foo", 
    "case-created-date": "2013-11-01" 
    ..... <more case attributes here> 
}

注意，到「newest_user」指向一個用戶，並且該引用是不透明的（即，你不會這樣做能夠在沒有服務器給你那個價值的情況下猜測它）。從技術上講，在這樣的架構中，所有的URL都應該被看作是不透明的（即使它們中的一部分是人類可讀的，並以resource/id/subresource的方式組織）。

所以當你去編寫你的API指南時，你可以指定每個鏈接關係的含義（在這種情況下，用戶，newest_user和消息），並且客戶端會知道他們在每個鏈接後得到的結果，不管URL看起來像什麼。

順便說一下，這種類型的信息在REST世界中被稱爲超媒體作爲應用狀態引擎，也稱爲「超媒體約束」。這是REST統一接口約束的要求。

來源

2013-12-19 04:48:18

REST資源相關數據

回答

相關問題