是使用自定義JSON內容類型是個好主意

我設計一個RESTful API和企圖是描述性的，使文檔更清晰我要聲明我的內容類型HTTP頭如下：是使用自定義JSON內容類型是個好主意

Content-Type: application/vnd.mycorp.mydatatype+json

其中mycorp是我公司唯一的標識符，mydatatype對每種數據類型都是唯一的。一個例子是：

Content-Type: application/vnd.ford.car+json 

{ 
"manufactured_year": 2000 
, "color": "blue" 
, "hp": 160 
, "model" "Focus" 
, "type": "sedan" 
}

這個內容類型將是必需的，以使POST有效並且將作爲響應的一部分發送。在我看來，這是一種很好的方式來定義有效負載內應該有的規則。

我似乎無法找到一個好的資源，看這是一個好主意，還是IETF標準允許的。

所以，問題是：哪個更可行，application/vnd.mycorp.mydatatype + json還是應用程序/ json？

來源

2012-11-08 gardarh

這是允許的，絕對。這是否是一個好主意是另一回事。

我的經驗法則是，它是一種主要的數據格式，它在很多事情中都很有用，需要自行識別，並且您需要在許多應用程序之間進行互操作，絕對可以爲它提供媒體類型。

但是，如果它只是一個你的API中還有許多消息，這只是一個資源（或一個資源「類型」）不錯，只是使用的應用程序/ JSON。

YMMV，當然。

來源

2012-11-09 05:51:55

這是一個好的觀點。大問題當然是什麼是「主要數據類型」，什麼不是。我有一個由我的文檔定義好的數據類型......但是RPC API始終是這種情況，我很少發現使用這種方法的人表示它們的數據類型。我想知道是不是這是因爲這不是一個好方法，或者API實現者通常不會考慮這個問題。 – gardarh

問題是密切相關的REST API 版本。

內容類型用於定義內容的類型。如果使用標準內容類型一樣

application/json

你說給客戶端，該消息是JSON格式。這對於所有不使用API版本或僅支持最新版本的Web應用程序來說已經足夠了。如果您打算讓客戶使用您的API的不同版本，標準內容類型是不夠的。考慮以下情形：

把你的例子作爲消息

Content-Type: application/vnd.ford.carV1+json 

{ 
"manufactured_year": 2000 
, "color": "blue" 
, "hp": 160 
, "model" "Focus" 
, "type": "sedan" 
}

1版本在某些時候，你決定表示使用十六進制代碼的顏色。因此，您創建類型

Content-Type: application/vnd.ford.carV2+json 

{ 
"manufactured_year": 2000 
, "color": "0000FF" 
, "hp": 160 
, "model" "Focus" 
, "type": "sedan" 
}

版本2當客戶端請求車指定了正確的內容類型，其中包括版本。這告訴應用程序是否將顏色作爲十六進制代碼或名稱發送。

這裏你版本資源的表示。支持資源表示版本的替代方法是將版本添加爲自定義標題（同時保留內容類型標準）

Content-Type: application/json 
Message-Version: 1.0

來源

2014-11-23 16:00:08 OGrandeDiEnne

是使用自定義JSON內容類型是個好主意

回答

相關問題