我试图了解基于 REST 的 API 到底是什么。据我了解，这只是在 API 中编写函数的约定？所有函数都应该是 GET/POST/DELETE/PUT 形式？因此，例如，REST API 中的函数可以是
public string getLastName(User x)
{
return x.lastName;
}
我主要对 JSON/XML 如何在其中发挥作用感到困惑？
【问题讨论】：
RESTful 服务最适合CRUD 操作和通过单个接口访问资源。这是SOAP 的更简化版本。 SOAP 最擅长暴露操作和暴露应用逻辑。
这不仅仅是一个约定。 REST API 背后的概念是您使用 HTTP 动词访问它，并且这些动词的功能已被映射以执行所描述的操作。
例如：
GET 会将数据返回给调用者/发送者
DELETE 将删除一条记录
而且它走得更远，但很多都是基于依赖 HTTP 来提供一定程度的一致性。例如，在 RESTful 服务中，您可以使用 Accept HTTP 标头通过分别提供 application/json 或 application/xml 值来请求 JSON 响应或 XML 响应。这只是一个简单的例子，由实现者决定他们的 API 将如何工作，但它强调了利用 HTTP 的重要性。
为什么选择 JSON/XML？
同样，使用 JSON 和 XML 是因为它们是通过 Web 表示和传输数据的广泛且标准的方式。由于大多数请求来自 JavaScript，JSON（JavaScript 对象表示法）在进行数据传输（尤其是 GET 请求）中非常常见，并且 JS 可以轻松地与 JSON 交互，而无需在处理 XML 时进行所需的解析。另一方面，XML 提供了自己的好处，例如使用模式和名称空间的能力。您可能已经知道每种方法的优点/缺点，但这是一个单独的讨论。要点是 JSON/XML 是在 REST API 中传输数据的主要方式，因为它们都是 Web 的事实标准。
有很多很好的资源可以获得更多信息，这篇 MSDN 文章可能会有所帮助：http://msdn.microsoft.com/en-us/library/dd203052.aspx
【讨论】：
围绕 REST 存在很多混淆和误解。不幸的是，与真正的 REST 应用程序相比，发现执行与 REST 含义完全相反的应用程序并称自己为 RESTful 的情况要常见得多。
据我了解，这只是在 API 中编写函数的约定？
不，REST 不仅是在 API 中编写函数的约定，也与此处其他答案所说的 SOAP 或 HTTP 直接相关。 REST 是一种软件架构风格，其灵感来自为 Web 本身做出的成功设计决策。简单来说，REST API 应该像网站一样工作。
当您进入一个网站时，您会进入一个主页，了解该网站的内容，HTML 文档将包含指向您所需资源的超链接。唯一的带外信息是资源本身的媒体类型，而不是如何找到它们。例如，当您进入 StackOverflow 时，您就知道问题和答案是什么，并寻找指向它们的链接。您的浏览器如何呈现这些链接、您如何选择和关注它们与其他网站（如电子邮件或新闻网站）没有什么不同。它的不同之处在于您所追求的资源的媒体类型。
这就是 REST API 的工作方式。除了详细说明资源的作用之外，客户端不应依赖任何带外信息。他们应该连接到一个主页，该主页返回他们应该遵循的链接来做他们需要的任何事情。如果 API 不这样做，那么它就不是 REST。期间。
我喜欢将这些 API 称为“street-REST”，因为人们经常通过复制他们在其他也称自己为 REST 的 API 中看到的内容以及其他人谈论 REST 的内容来实现它们。
所有函数都应该是 GET/POST/DELETE/PUT 形式？
这是一个常见的混淆，你会看到很多，包括人们将其与 CRUD 操作混为一谈，或者 REST 不允许任何其他动词等。这很牛。
REST 独立于任何特定协议，因此说函数应该遵循 HTTP 方法是没有意义的。 REST 将您的应用程序限制在一个统一的接口中，这意味着无论您应该使用什么协议，您都必须尽可能地坚持标准化的行为。如果您通过 HTTP 实现 REST 应用程序，这意味着您的 API 必须坚持使用 HTTP 方法进行客户端-服务器交互，这意味着您不能像某些使用 HTTP 的应用程序那样发明其他 HTTP 方法。如果您更改通信协议，客户端需要在输入您的 API 之前知道该信息，这就是更多的带外信息。
如何在代码中实现这一点与 REST 无关。 REST 不是一种开发模式或哲学，而是一种架构风格。
我主要对 JSON/XML 如何在其中发挥作用感到困惑？
对此也有很多困惑。在 REST 应用程序中，您应该使用描述您需要的所有行为的 states 定义抽象实体。 API 将用作在客户端和服务器之间传输这些实体的媒体类型表示的渠道。 REST 表示具象状态转移。客户端请求的 URI 是该资源的标识符，该请求的元数据将告诉服务器客户端准备接受哪些媒体类型。 JSON/XML 在 REST 中根本没有任何直接作用。它们只是一种表示媒体类型，与文本/html 等格式相比，它更容易让计算机解析和获取信息，而文本/html 旨在通过浏览器呈现以供人类可视化。
以 StackOverflow 本身为例。抽象意义上的问题是什么？这是一个信息请求。该抽象资源是如何正式定义的？有作者，有被问问题的实际文本，有赞成票和反对票，cmet 和可能的答案等，所有这些也是具有自己定义的抽象资源。实际数据存储在某处的数据库中，当您请求主页时，它会返回带有标识这些问题的 URI 的链接。以这个问题为例，它的 URI http://stackoverflow.com/questions/24092517。当我想在浏览器上呈现的漂亮文档中阅读该问题时，我将请求该 URI，但通过 Accept 标头告诉服务器我想要 text/html 表示，并且我的浏览器知道如何呈现 HTML变成漂亮的一页。另一方面，当我想请求将该问题存储回数据库时，例如，我不需要呈现漂亮文档页面所需的所有可爱的东西，所以我要求一种更容易解析和不包含很多不必要的信息，例如 JSON 或 XML。
大多数构建 street-REST API 的人都理解这一点，但他们忽略了最有趣的部分，那就是您不仅限于已经存在的媒体类型。您可以创建仅存在于您的 API 或您公司的应用程序生态系统中的私有媒体类型。因此，例如，不是调用所有 JSON 文档的媒体类型application/json，无论它们的内容是什么，我们都可以拥有更准确地反映该特定资源类型的自定义媒体类型。因此，对于以 JSON 格式表示的 StackOverflow 问题，我们可以有一个 application/vnd.stackoverflow.question.v1+json。一旦你这样做了，而不是浪费时间记录通信协议已经标准化的操作，你应该专注于记录自定义媒体类型以及如何与之交互，独立于通信协议。一旦你明白这一点，客户就可以使用任何可用的协议与你的服务进行交互。
如果您了解这三个要点，您就了解 REST 是什么。通过使用超链接作为应用程序状态的引擎，您不会被绑定到任何特定的实施时间点。您的服务器可以随意发展，您可以随意更改 URI，并且客户端不会中断。通过坚持标准化的协议，通用客户端更容易使用您的 API，更不用说如果开发人员已经知道您不会破坏协议，他们更容易理解如何集成。通过将您的设计和文档工作集中在您的媒体类型上，而不是协议细节和 URI 语义上，您可以避免引入更多驱动 API 所需的带外信息，并且您的客户也更能适应变化。
【讨论】：
REST API 充当中间人，在 Web 服务和应用程序之间传递数据包，该应用程序想要使用 Web 服务中的一些资源进行操作，为此，Json 发挥了作用，这有助于通过渠道。当应用程序想要获取资源列表时，实际上是从数据库中获取复杂数据或查询集，这些数据通过序列化转换为简单数据类型，然后转换为 json 来遍历通道。
【讨论】：
RESTful API 不仅仅是编写函数的约定。
缩写 REST 代表“REpresentational State Transfer”。
REST API 用于调用资源并允许软件基于标准化的原则、属性和约束进行通信。 REST API 在简单的请求/响应系统上运行。您可以使用以下 HTTP 方法发送请求：
此外，REST API 可以包括端点、标头、URL 参数和请求正文。
端点（或路由）是您请求的 URL。路径决定了您请求的资源。可以把它想象成一个自动应答机，它要求您按 1 进行服务，按 2 进行另一项服务，按 3 进行另一项服务，依此类推。
我主要对 JSON/XML 如何在其中发挥作用感到困惑？
当您向端点发送请求时，它会使用相关数据进行响应，这些数据通常格式为 JSON、XML、纯文本、图像、HTML 等。
【讨论】：
我主要对 JSON/XML 如何在其中发挥作用感到困惑？
JSON/XML 被称为流数据格式。还有其他的，但多年来，这两个由于它们提供的低延迟而变得如此受欢迎。 XML 可能仍然比 JSON 更受欢迎，但 JSON 更紧凑。
使用它们的另一个主要原因是，几乎所有语言及其框架都支持它们。
【讨论】：