REST API設計，使用哪種模式

Question

我需要針對移動應用程序的更快的REST API。 我為API設計了兩種類型的響應。 哪種方法更好？ **

• 選項1

**

{    
  data :[ 
          {name:"abc",email:"abc@abc.abc",id:12,age:24},
          {name:"abc",email:"abc@abc.abc",id:13,age:24}
        ]
}

**

• 選項2

**

{
     fields:['name','email','id','age'],
     values:[
                ['abc','abc@abc.abc',12,45],
                ['abc','abc@abc.abc',12,45]
            ]
}

顯然，第二個鍵產生的響應長度更短（考慮到單個響應中有1000條記錄的情況）和更快的輸出，因為不重復鍵。

有人可以建議最好的做法嗎？

Answer 1

選項1是大多數API的通用標准 。 由於大多數庫（GSON，Jackson等）在設計時都考慮了＃1的問題，因此它使解析和映射JSON響應到模型類的映射變得更加容易。 我強烈建議您選擇＃1。 ;）

此外，如果您在路上引入嵌套對象，則＃2會使事情變得復雜。

您可以在此處閱讀有關JSON規范的更多信息。

Answer 2

我喜歡第一個。 為什么？ 因為在軟件開發中有一個不變的事實，那就是CHANGE 。 如果系統不更改，它將很快消失，因此，為將來的更改做准備，您應該使用＃1。 您可以添加字段，也可以刪除字段，並告訴客戶端例如在使用前檢查字段是否存在。 您還可以使自己與字段排序分離。 您還可以使將來的開發人員更輕松地使用您的系統。 這就是每個系統都使用＃1的原因，為了減小大小，您可以使用Gzip。

祝好運。

Answer 3

由於選項1的可讀性和可維護性，因此應由開發人員選擇。 我同意關於嵌套對象的觀點。 為了提高速度，JSON一直支持不同的語言，並且可以壓縮以使文件更小，因為它是由文本組成的，並且盡可能使用gzip進行90％的壓縮。

Answer 4

確實是一個。 使用對象表示法，因為它應該被使用。 比2更具可讀性，更易於擴展，解析和操作。