REST是一种编写分布式应用程序的架构模式和风格。它不是狭义的编程风格。

说你使用REST风格类似于说你建造了一个特定风格的房子：例如都铎风格或维多利亚风格。REST作为一种软件风格，都铎或维多利亚风格作为一种家居风格，都可以通过构成它们的质量和约束来定义。例如，REST必须具有客户端-服务器分离，其中消息是自我描述的。都铎风格的房屋有重叠的山墙和屋顶，这些山墙和前面的山墙陡峭倾斜。您可以阅读Roy的论文，以了解更多关于构成REST的约束和质量的信息。

与家庭风格不同的REST在持续和实际应用中遇到了困难。这可能是故意的。将其实际实现留给设计者。所以你可以自由地做你想做的事情，只要你满足论文中提出的约束条件，你就可以创建REST系统。

奖金：

整个web都基于REST（或REST基于web）。因此，作为一名web开发人员，您可能需要意识到这一点，尽管编写好的web应用程序并不必要。

REST是一种编写分布式应用程序的架构模式和风格。它不是狭义的编程风格。

说你使用REST风格类似于说你建造了一个特定风格的房子：例如都铎风格或维多利亚风格。REST作为一种软件风格，都铎或维多利亚风格作为一种家居风格，都可以通过构成它们的质量和约束来定义。例如，REST必须具有客户端-服务器分离，其中消息是自我描述的。都铎风格的房屋有重叠的山墙和屋顶，这些山墙和前面的山墙陡峭倾斜。您可以阅读Roy的论文，以了解更多关于构成REST的约束和质量的信息。

与家庭风格不同的REST在持续和实际应用中遇到了困难。这可能是故意的。将其实际实现留给设计者。所以你可以自由地做你想做的事情，只要你满足论文中提出的约束条件，你就可以创建REST系统。

奖金：

整个web都基于REST（或REST基于web）。因此，作为一名web开发人员，您可能需要意识到这一点，尽管编写好的web应用程序并不必要。

REST是一种分布式系统（如WWW）软件架构风格，您可以想象它是一个精心设计的Web应用程序规则：一组Internet网页（一个虚拟状态机），其中通过单击链接（状态转换）进行超链接，结果是下一个网页（这意味着应用程序的下一个状态）。

REST描述了网络系统由三部分组成：

数据元素（资源、资源标识符、表示）连接器（客户端、服务器、缓存、解析器、隧道）组件（源服务器、网关、代理、用户代理）

REST严格满足以下条件：

应用程序功能的状态被划分为资源用作超链接定位语法的每个资源（例如，在WWW URI中）所有资源在具有资源转换状态的客户端之间共享统一接口，包括：有限的一组定义良好的操作（如HTTPGET/POST/PUT/DELETE）一组有限的内容格式内容类型，可能包括可执行代码（例如，在WWW Javascript中）

这个答案是针对初学者的，让我们了解一下目前最常用的API架构。

了解Restful编程或Restful API。首先，您必须了解什么是API，在一个非常高级的API上，它代表应用程序编程接口，它基本上是一个软件，可以由另一个软件使用，以允许应用程序相互对话。

全球使用最广泛的API类型是web API，而每当有请求时，它都会向客户端发送数据。

事实上，API不仅用于发送数据，而且并不总是与web开发、javascript、python或任何编程语言或框架相关。

API中的应用程序实际上可以意味着许多不同的事情，只要软件的pice是相对独立的。以文件系统或HTTP模块为例，我们可以说它们是一小块软件，我们可以使用它们，我们可以通过使用它们的API与它们进行交互。例如，当我们对任何编程语言的文件系统模块使用read-file函数时，我们实际上使用的是file_system_reading API。或者，当我们在浏览器中进行DOM操作时，我们实际上并不是在使用JavaScript语言本身，而是在使用浏览器向我们公开的DOM API，因此它为我们提供了访问它的权限。或者，再举一个例子，让我们用Java等任何编程语言创建一个类，然后向其添加一些公共方法或财产，这些方法将成为从该类创建的每个对象的API，因为我们给其他软件提供了与我们的初始软件（在本例中为对象）交互的可能性。S0，API实际上具有比构建web API更广泛的含义。

现在让我们来看看构建API的REST体系结构。

REST（代表代表性状态转移）基本上是一种以逻辑方式构建web API的方式，使其易于为自己或他人使用。

要按照REST架构构建Restful API，我们只需要遵循几个原则。1.我们需要将API分成逻辑资源。2.然后应使用基于资源的URL公开这些资源。3.要对数据执行不同的操作，如读取、创建或删除数据，API应使用正确的HTTP方法，而不是URL。4.现在，我们实际发送回客户端或从客户端接收到的数据通常应该使用JSON数据格式，如果应用了某种格式标准。5.最后，EST API的另一个重要原则是它们必须是无状态的。

将API分离为逻辑资源：REST中信息的关键抽象是一种资源，因此，我们希望在API中共享的所有数据都应该划分为逻辑资源。什么是资源？好吧，在REST的上下文中，它是一个对象或某个事物的表示，它有一些与之相关的数据。例如，像导游、用户、地点或评论之类的应用程序就是逻辑资源的例子。因此，基本上任何可以命名的信息都可以是资源。不过，只需要命名，而不是动词。

暴露结构：现在我们需要暴露，这意味着使用一些结构化的URL来提供数据，客户端可以向其发送请求。例如，像这样的整个地址被称为URL。并且调用了这个/addNewTour和API端点。

我们的API将有许多不同的端点，如下所示

https://www.tourguide.com/addNewTour
https://www.tourguide.com/getTour
https://www.tourguide.com/updateTour
https://www.tourguide.com/deleteTour
https://www.tourguide.com/getRoursByUser
https://www.tourguide.com/deleteToursByUser

这些API中的每一个都会将不同的数据发送回客户端，并执行不同的操作。现在，这里的这些端点有一些非常错误的地方，因为它们确实没有遵循第三条规则，即我们应该只使用HTTP方法来对数据执行操作。因此，端点应该只包含我们的资源，而不是我们对其执行的操作，因为它们很快就会成为维护的噩梦。

我们应该如何在实践中使用这些HTTP方法？好了，让我们看看这些端点实际上应该是如何以/getTour开头的。所以这个getTour端点是为了获取关于一个旅游的数据，所以我们应该简单地命名这个端点/旅游，并在向这个端点发出get请求时发送数据。换句话说，当客户端使用GET HTTP方法访问端点时，

（我们只有端点或URL中的资源，没有动词，因为动词现在在HTTP方法中，对吗？通常的做法是总是使用复数形式的资源名称，这就是我写/tours或/tours的原因。）惯例是，当调用端点/游览时，将返回数据库中的所有游览，但如果我们只希望游览具有一个ID，比如说七个，我们会在另一个斜杠（/tours/7）或搜索查询（/tours？ID=7）中添加七个，当然，它也可以是游览的名称而不是ID。

HTTP方法：这里真正重要的是端点名称如何与所有端点名称完全相同。

GET: (for requesting data from the server.)

https://www.tourguide.com/tours/7
POST: (for sending data to the server.)
https://www.tourguide.com/tours
PUT/PATCH: (for updating requests for data to the server.) https://www.tourguide.com/tours/7
DELETE: (for deleting request for data to the server.)
https://www.tourguide.com/tours/7

PUT和PATCH之间的差异->通过使用PUT，客户端应该发送整个更新的对象，而使用PATCH，客户端应该只发送已更改的部分对象。

通过使用HTTP方法，用户可以执行基本的四个CRUD操作，CRUD代表创建、读取、更新和删除。

现在可能会出现如下情况：

因此，/getToursByUser可以简单地转换为/users/tours，对于第3号用户，终点将类似/users/3/tours。

如果我们想删除特定用户的特定游览，那么URL应该是/users/3/tours/7，这里是用户id:3和游览id:7。

因此，像这样整合资源的可能性真的很多。

以JSON形式发送数据：现在，关于客户端实际接收到的数据，或者服务器从客户端接收到的，我们通常使用JSON数据格式。典型的JSON可能如下所示：在发送JSON数据之前，我们通常会进行一些简单的响应格式化，这有几个标准，但其中一个非常简单的标准叫做Jsend。我们只需创建一个新对象，然后向其添加一条状态消息，以通知客户端请求是成功、失败还是错误。然后我们将原始数据放入一个名为data的新对象中。

像我们在这里所做的那样，将数据包装到一个额外的对象中称为包络，这是缓解一些安全问题和其他问题的常见做法。

Restful API应该始终是无状态的：最后，Restful API应该总是无状态的，这意味着，在无状态的Restful API中，所有状态都在客户端处理，而不是在服务器上。状态只是指应用程序中可能随时间变化的一段数据。例如，某个用户是登录的还是在一个包含多个页面的列表的页面上，当前页面是什么？现在，状态应该在客户端上处理这一事实意味着每个请求都必须包含在服务器上处理特定请求所需的所有信息。因此，为了处理当前请求，服务器永远不必记住以前的请求。

让我们假设目前我们在第五页，我们想前进到第六页。因此，我们可以有一个名为/tours/nextPage的简单端点，并向服务器提交一个请求，但服务器必须确定当前页面是什么，并根据该页面将下一个页面发送给客户端。换句话说，服务器必须记住先前的请求。这正是我们希望在RESTful API中避免的。

我们应该创建一个/tours/page端点，而不是这种情况并将数字6粘贴到其上，以请求第6页/游览/第6页。所以服务器不必记住其中的任何内容，它所要做的就是按照我们的要求发回第六页的数据。

无状态和无状态是计算机科学和一般应用中非常重要的概念

本质上没有“RESTful编程”这样的概念。它最好被称为RESTful范式，甚至更好的RESTful架构。它不是一种编程语言。这是一个范例。

来自维基百科：

在计算中，表示状态转移（REST）是一种用于web开发的体系结构风格。

REST==HTTP类比是不正确的，除非你不强调它“必须”是HATEOAS驱动的。

罗伊自己在这里清除了它。

输入REST API时，除了初始URI（书签）和适用于预期受众的一组标准化媒体类型（即，预期任何可能使用该API的客户端都能理解）之外，不应有任何先验知识。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收的表示中，或者由用户对这些表示的操作来暗示。转换可以由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以动态地改进（例如，按需编码）。

[这里的失败意味着带外信息正在驱动交互，而不是超文本。]