1

I'm creating REST API that will be used by a web page.
There are several types of data I should provide, and I'm wondering what would be the best practice:

  1. Create one method that will return a complex object with all the needed data.
    • Pros: one call will be needed from the UI side to get all the data.
    • Cons: not generic solution at all.
  2. Create multiple autonomous method.
    • Pros: generic enough to be used in the future by other components.
    • Cons: will require the UI to make several calls to the server.

Which one adheres more to best practices?

4

2 回答 2

2

它最终取决于您的环境、数据大小和方法的数量。但是有几个理由选择第二种选择，只有一个选择第一种。

第一种选择：一种复杂的方法

选择第一个的原因：多个请求的 HTTP 开销。

是否存在开销？当然可以，但真的那么高吗？HTTP 是最轻量级的应用层协议之一。它的设计开销很小。它的简单性和轻巧的标题是其成功的一些主要原因。

第二种选择：多种自治方法

现在有几个理由选择第二种选择。相信我，即使数据很大，它仍然是一个更好的选择。让我们讨论一些方面：

  • 如果数据量很大
    • 将数据传输分成更小的部分会更好。
    • HTTP 是一种尽力而为的协议，数据故障非常普遍，特别是在 Internet 环境中 - 应该如此普遍。数据块越大，必须重新请求所有内容的风险就越大。
  • 方法的数量：可维护性、重用性、组件化、可学习性、分层......
    • 您自己说过，通用解决方案更容易被其他组件使用。方法的职责越简单和简洁，就越容易理解它们并在其他方法中重用它们。
    • 它更容易维护和学习：它们越独立，就越不需要知道如何更改它（或摆脱一个错误！）。

在这里考虑 REST 很重要，但是将组件分解成更小的部分的原因实际上来自于理解 HTTP 协议和良好的编程/软件工程。

于 2013-06-29T19:16:49.383 回答
0

所以，事情是这样的：REST 很棒。但并非所有最纯粹形式的模式都适用于所有情况。如果效率是一个问题，请走一通电话的路线。或者可能同时提供两者，如果其他人会使用它并且可能不需要每次都拉下完整的复杂对象。

我想说 REST 不关心数据规范化。有两种方法来获取相同的数据不会受到伤害。

于 2013-06-29T18:59:57.670 回答