我們正在三個系統之間進行集成（我們稱它們爲A，B和C）。我們可以控制的A和B系統，我們不能控制的C。 三個系統之間的邏輯是這樣的 - A與B通信，B與C通信。 全部使用REST web服務。我們無法控制的，使用內容類型application/json。 B現在使用text/html，因爲有舊的集成（與C），這已使用。與A完全沒有集成。REST - 內容類型選擇
所以我想知道如果它更好地重做B系統從零開始，並使其爲每個系統使用相同的內容類型application/json或保持原樣（就像沒有太大的區別）？
也有任何優點/缺點我應該使用application/json而不是html？
更新 對不起，我忘了提及，這將完全用於傳輸業務數據，如果這是任何使用。
TLDR - 使用JSON當它涉及到Web服務，你必須服完不管客戶端要求（和你支持）
現實。客戶端可以通過使用HTTP Accept頭來指定他們想要接收的數據類型，它取決於您的Web服務（或您使用的Web服務框架）以相應地序列化響應。
說到使用HTML或JSON提供服務數據的區別，它們是針對兩種不同的使用情況。 HTML通過「標記」（HTML中的M）發送，其中包含有關如何通過瀏覽器查看數據的說明。對於另一個不是瀏覽器的客戶而言，只是在尋找數據，解析這些數據是一個額外的不必要的步驟，如果沒有第三方庫或一堆手動代碼，通常不會自動支持該步驟。
JSON（以及XML和CSV等其他格式）僅用於傳輸數據及其可能的關係，而反序列化通常由許多不同的客戶端編程語言（包括.NET，JavaScript等）本機支持。因爲它只是數據，所以客戶不必嘗試從任何額外的無關標記中提取數據。
此外，客戶端Web應用程序接收JSON並在客戶端創建HTML比接收HTML並僅在需要時解析出數據要容易得多。此外，您允許客戶創建特定於其應用程序的HTML，而不是嘗試操縱Web服務發送給他們的特定應用程序的HTML。
這就像問你是否應該使用索引卡片或小說。 HTML和JSON旨在表達非常不同的內容。他們不適合做同樣的工作，而且一個本質上並不比另一個更好。 – Quentin 2015-02-11 14:29:21
@Quentin因此，要善待並分辨這些差異，因爲現在我們的系統中使用了兩種不同類型的相同數據，我認爲這並不好。 – Andrius 2015-02-11 14:35:16