從REST API

在REST API的上下文中擷取所接受的報頭，例如，在Allowheader response字段是獲取有用： 用於指定資源有效動作。從REST API

例子：

Allow: GET, HEAD

也有爲了獲得接受列表接受頭一個衆所周知的領域？一些諸如：

Accept: application/vnd.company.api.com.foo+json;v=42, application/vnd.company.api.com.foo+xml;v=42

來源

2013-10-28 Doug

您確實需要自動發現此信息嗎？一般來說，支持的媒體類型是帶外信息，對於您的情況（因爲您使用的是大概未註冊的媒體類型），它肯定會*是帶外信息。 –

我同意，因爲在給定的例子中，「foo」不是超媒體類型。自動發現此信息的能力可能對長期有用，其中一個API（沒有任何版本）可能會首先使用HAL，之後在2年後切換到Siren ... 我認爲這會很危險，難以過多地陷入困境，並決定在API的整個生命週期中使用特定的超媒體語言。明天又是新的一天。 – Doug

沒錯。通過使用根菜單選項作爲宣傳它支持的媒體類型的地方，服務器不僅可以發佈它支持的媒體類型，還可以在更細粒度的級別上發佈（因爲您可以改變每個鏈接支持的媒體類型資源）。 –

這是由客戶端告訴服務什麼都可以接受，因爲沒有了一大堆，如果它不能接受的響應（客戶端可以做它止跌」不知道如何處理返回的媒體類型）。

如果服務器不能夠創建符合一個資源表示的，它可以做兩件事情之一：

發送406無法接受
發送不符合的響應Accept報頭（HTTP 1.1）

如果服務器發送406，根據RFC 2616，只要它不是一個HEAD請求「的響應應該包括含有的可用的實體特性和位置的列表中的一個實體（s）from用戶或用戶代理可以選擇最合適的一個。實體格式由在Content-Type首部字段中給出的媒體類型指定「。

在普通的英語，這意味着所述響應應該通過到內容的鏈接，它可以提供陪同。媒體類型可以是由輪廓屬性附加到包含鏈接（雖然按介質類型而異）溝通。

一種方式來學習的服務器提供什麼樣的媒體類型是通過在根提供的鏈接的菜單，發現他們URI（使用衆所周知的媒體類型）。例如，您對/的請求可能會指定text/html的接受標題並接收以下re sponse：

<html> 
    <head> 
    <link rel="foo" type="application/vnd.company.api.com.foo+json;v=42" href="http://v42.api.com/foos/3713678123" /> 
    <link rel="foo" type="application/vnd.company.api.com.foo+json;v=43" href="http://v43.api.com/foos/3713678123" /> 
    </head> 
</html>

來源

2013-10-28 21:34:24

謝謝，Jonathan W！ – Doug

回答

相關問題