Rest

本文将介绍如何应用 Apifox 开发 REST API，并展现 Apifox 的一些要害性能。 咱们能够先理解下：REST API 简介 - RESTful Web 服务 步骤 1：创立一个 Apifox 账户首先，你须要在 Apifox 上创立一个账户。 步骤 2：创立一个我的项目在 Apifox 首页中，你能够创立一个新我的项目。在我的项目中，你能够增加 API 标准和 测试用例。要创立一个新我的项目，请单击首页上的 "创立我的项目" 按钮。而后输出项目名称并创立我的项目。 步骤 3：创立 API 接口在我的项目中，你能够创立一个新的 API 接口。其中，文档是 REST API 的蓝图，它形容了 API 的资源、操作和参数；运行次要是用来调试接口。接口运行完之后点击保留为用例按钮，即可生成接口用例，后续可间接运行接口用例，无需再输出参数，十分不便。要创立一个新的 API 接口，请单击我的项目页面上的 "创立接口" 按钮。 通过上述步骤你能够在 Apifox 上定好接口文档初稿。 步骤 4：接口评审在定义好 API 文档 初稿后，你须要协调前后端 一起评审、欠缺接口文档，确认好接口用例。在这个过程中，能够将合作人员都拉入我的项目空间中，基于 Apifox 你还能够随时查看文档的历史批改记录。 步骤 5：开发 REST API之后，你就能够在 IDE 中编写 API 代码。代码编写实现后，应用接口用例调试开发中接口，只有所有接口用例调试通过，接口就开发实现了。如开发过中接口有变动，调试的时候就自动更新了文档，零老本的保障了接口保护的及时性。在开发过程中，每次调试完一个性能就保留为一个接口用例。 步骤 6：测试 REST API在开发过程中，测试人员也能够间接应用接口用例 测试接口。所有接口开发实现后，测试人员应用汇合测试性能进行多接口集成测试，残缺测试整个接口调用流程。 ...

REST 是 Representational State Transfer 的缩写，是 Roy Fielding 于 2000 年提出的一种通过 HTTP 设计涣散耦合应用程序的架构格调，其次要利用于 Web 服务的开发。REST 不是强制性的，能够不恪守，但它提供了一种高级设计指南。 架构束缚REST 定义了六种架构束缚来形成 Web 服务。RESTful API 是指应用 HTTP 并遵循 REST 准则的 API。这些架构束缚有以下作用： 进步零碎的可伸缩性和可靠性：通过客户端-服务器拆散、无状态和分层零碎等架构束缚，使零碎更容易扩大和保护，进步零碎的可靠性；进步零碎的性能：应用缓存能够缩小对服务器资源的耗费，从而进步零碎的性能和可伸缩性；进步零碎的安全性和隔离性：分层零碎能够提供更好的安全性和隔离性，使零碎更加安全可靠；升高开发和保护老本：通过对立接口能够使开发人员更加容易地了解和应用 API，同时按需代码能够缩小服务器端的负载，进步了客户端的灵活性和可扩展性。一个 RESTful API，须要满足以下六大架构束缚： 对立接口CS (客户端-服务器拆散)无状态缓存零碎分层按需编码（可选）接下来咱们来具体看看这六大架构束缚。 CS（客户端-服务器拆散）这是 REST 格调的根本准则之一：将客户端和服务器之间拆散，使其可能别离进行演变和扩大，进步了零碎的可伸缩性和可靠性。通过客户端-服务器拆散，客户端和服务器能够别离由不同的开发团队进行开发和保护，并且能够使客户端和服务器之间的协定更加简略和清晰。 无状态服务器不应存储客户端的状态信息。每个申请都应该蕴含足够的信息以便服务器能够解决申请，这样能够使服务器更容易扩大，进步零碎的可伸缩性和可靠性。无状态的设计能够升高零碎的复杂度，并且能够缩小对服务器资源的耗费。 缓存服务器应该尽可能地应用缓存来进步性能和可扩展性。客户端能够缓存服务器返回的响应，以缩小对服务器的申请；服务器也能够缓存申请的响应，以缩小对后端系统的申请。缓存能够缩小网络带宽的应用，进步零碎的性能和可伸缩性。 对立接口REST 应用一组标准接口来实现客户端和服务器之间的通信。这些接口包含资源的标识、资源的示意、自描述音讯、超媒体作为应用程序状态的引擎等。通过应用这些标准接口，REST 能够使客户端和服务器之间的通信更加简略和牢靠。对立接口能够使开发人员更加容易地了解和应用 API。 分层零碎REST 容许零碎被分成多个档次，每个档次都能够有本人的性能。这样能够进步零碎的可伸缩性和可靠性，同时也提供了更好的安全性和隔离性。分层零碎能够使开发人员更加容易地扩大和批改零碎，也能够进步零碎的可靠性和安全性。 按需代码（可选）REST 能够通过向客户端传输可执行的代码（例如 JavaScript）来扩大客户端的性能。这样能够缩小服务器端的负载，同时也进步了客户端的灵活性和可扩展性。按需代码能够使开发人员更加容易地扩大和批改客户端性能。 最初须要留神的是，这些束缚并不是死的，如果违反了一两个，也不影响称为 RESTful API，但不合乎“真正的 RESTful”束缚。 常识扩大：理解更多 REST API 相干常识。 REST 与 SOAP 之间的差别REST API 罕用的平安认证形式

解释OAuth2技术正如我所说，我们将使用OAuth2协议，因此首先要解释这个协议是如何工作的。OAuth2有一些变体，但我将解释我将在程序中使用的内容，为此，我将给你一个例子，以便你了解我们打算做什么。举个例子，在商店里用信用卡付款。在这种场景下，有三个角色：商店、银行和我们。OAuth2协议中也发生了类似的事情，就像这样：1.客户或买方需要银行提供信用卡。然后，银行将收集我们的信息，核实我们是谁，并根据我们帐户中的资金向我们提供信用卡或者直接拒绝我们。在授予卡的OAuth2协议中，它称为身份验证服务器。2.如果银行给了我们卡，我们可以去商店，即网络服务器，我们提供信用卡。商店不欠我们任何东西，但他们可以通过读卡器向银行询问他们是否可以信任我们以及信用余额（信用余额）。商店是资源服务器。3.商店，根据银行说我们拥有的钱，将允许我们购买。在OAuth2类比中，Web服务器将允许我们访问页面，具体取决于我们的财务状况。如果您没有注意到通常使用身份验证服务器，当您转到网页并被要求注册时，它允许您通过Facebook或Google进行。Facebook或Google成为发行“卡”的“银行”，并会验证您的“信用”是否足够支付这个商品。您可以看到“El Pais”的网站并创建一个帐户。如果我们使用Google或Facebook，这个商店将依赖这些身份验证提供商提供的客户身份信息。在这种情况下，网站唯一需要的是拥有信用卡 - 无论余额如何创建授权服务器现在，让我们看看如何创建银行、商店以及您需要的所有其他内容。首先，在我们的项目中，我们需要具有适当的依赖关系。我们需要启动者：Cloud OAuth2，Security和Web。那么，让我们从定义银行开始; 这就是我们之前说的：  AuthorizationServerConfiguration：我们从 @ Configuration 标签开始，然后使用  @EnableAuthorizationServer 标记告诉Spring激活授权服务器。要定义服务器属性，我们指定我们的类扩展  AuthorizationServerConfigurerAdapter，实现了  AuthorizationServerConfigurerAdapter接口，所以Spring将使用这个类来参数化服务器。我们定义了一个Spring自动提供的AuthenticationManager ，我们将使用它来收集@Autowired标签。我们还定义了一个  TokenStore对象，作为public的功能 。 虽然 AuthenticationManager由Spring提供的，但我们必须自己配置它。我等等解释要如何完成这个配置。TokenStore或者IdentifierStore是身份验证服务器提供的标识符将存储的位置，因此当资源服务器（商店）要求信用卡上的信息时，身份验证服务器就要响应它。在这种情况下，我们使用  InMemoryTokenStore将标识符存储在内存中的类。在实际应用中，我们可以使用JdbcTokenStore将它们保存在数据库中，以便在应用程序发生故障时，客户端不必更新其信用卡。在功能配置中 (ClientDetailsServiceConfigurer clients)，我们指定银行的凭证，包括身份验证的管理员，以及提供的服务。因为要访问银行，我们必须为每个提供的服务提供用户名和密码。这是一个非常重要的概念：用户名和密码来自银行，而不是客户。对于银行提供的每项服务，将进行单一认证，但对于不同的服务可能相同。我将详细说明这些内容： clients.inMemory ()指定我们将服务存储在内存中。在“真正的”应用程序中，我们将其保存在数据库，LDAP服务器等中。 withClient ("client")是我们将在银行中识别的用户。在这种情况下，它将被称为“客户端”。将他称为“用户”会不会更好？ 要  uthorizedGrantTypes ("password", "authorization_code", "refresh_token", "implicit") ，我们指定配置定义的用户，对服务“ 客户端 ”。在我们的示例中，我们将仅使用密码服务。 authorities ("ROLE_CLIENT", "ROLE_TRUSTED_CLIENT", "USER") 指定所提供服务包含的角色或组。我们也不会在我们的例子中使用它，所以让我们让它暂时运行。 scopes ("read", "write")  是服务的范围 - 我们也不会在我们的应用程序中使用它。 autoApprove (true)-如果您必须自动批准客户的请求，我们会说是，以使应用程序更简单。 secret (passwordEncoder (). encode ("password")) 是客户端的密码。请注意，调用我们稍后定义的编码函数来指定密码将保存在何种类型的加密中。的编码功能进行注释与@Bean标签因为Spring，当我们在HTTP请求中提供密码时，会查找一个  PasswordEncoder对象检查交付密码的有效性。最后，我们有一个函数   configure (AuthorizationServerEndpointsConfigurer endpoints) ，我们定义哪个身份验证控制器和标识符存储应该使用端点。澄清终点是我们将与我们的“银行”联系以请求卡的URL。现在，我们已经创建了我们的身份验证服务器，但是根据引入的凭据，我们仍然需要他知道我们是谁并将我们放在不同的组中的方式。好吧，为此，我们将使用与保护网页相同的类。现在，我们可以检查我们的授权服务器是否有效。让我们看看如何使用优秀的PostMan程序。我们将使用HTTP请求类型POST，表明我们要使用基本验证。在我们的示例中，我们将分别使用“client”和“password”来设置用户和密码，即“银行”的密码。在请求正文和form-url编码格式中，我们将介绍要请求的服务，用户名和密码。'access_token'“ 8279b6f2-013d-464a-b7da-33fe37ca9afb ”是我们的信用卡，是我们必须提供给我们的资源服务器（商店）以查看非公开的页面（资源）的信用卡。创建资源服务器（ResourceServer）现在我们有了信用卡，我们将创建接受该卡的商店。在我们的示例中，我们将使用Spring Boot在相同的程序中创建资源和身份验证服务器，它无需配置任何内容。如果像现实生活中一样，资源服务器在一个地方，而身份验证服务器在另一个地方，我们应该向资源服务器指出哪个是我们的“银行”以及如何与之交谈。但是，我们将把它留给另一个条目。资源服务器的唯一类是  ResourceServerConfiguration：由于身份验证和资源服务器在同一个程序中，我们只需要配置资源服务器的安全性。这是在函数中完成的：一旦我们创建了资源服务器，我们必须只创建服务，这些服务是通过这些行完成的：现在让我们看看验证的工作原理。首先，我们检查我们是否可以在没有任何验证的情况下访问“/ publica”：如果我尝试访问“/ private”页面，则会收到错误“401 unauthorized”，表示我们无权查看该页面，因此我们将使用我们的授权服务器给用户授权。如果我们可以看到我们的私人页面，那么让我们尝试管理员的页面：我们当然没办法看到管理员的界面。因此，我们将要求凭据管理员提供新令牌，但要向用户“管理员”表明身份。返回的令牌是：“ab205ca7-bb54-4d84-a24d-cad4b7aeab57。” 这样就没问题了，我们可以安全地去购物！现在，我们只需要设置商店并拥有产品。本人创业团队产品MadPecker，主要做BUG管理、测试管理、应用分发，有需要的朋友欢迎试用、体验！本文为MadPecker团队产品经理译制，转载请标明出处

看到API你会想起什么？是接口、第三方调用、还是API文档？初看你可能会觉得这太熟悉了，这不是系统开发日常系列吗？但你仔细想一想，你会发现API的概念在你脑海里是如此的模糊。如果你通过搜索引擎检索API，你会看到类似这样的信息：API——Application Programming Interface(应用程序编程接口)，这太抽象了。接下来，我将结合在开发中总结的一些经验，以通俗的方式聊聊API、REST API、RESTful API以及Web Service这四者之间的联系与区别。 1、API 与 REST API 什么是API?这里引述维基百科给出的定义：应用程序接口（英语：Application Programming Interface，缩写：API；又称为应用编程接口）是软件系统不同组成部分衔接的约定。这个对API的定义太过于广泛和抽象，而通俗的讲，API是一段应用程序与另一段应用程序相互“交流”的方式（协议）。在Web应用程开发中，API是我们通过网络进行数据检索的一种主要方式，API文档将告知你检索数据的URL列表、查询参数、请求方式以及响应状态，其目的是降低Web应用程序开发难度，共享两个应用程序之间的数据（文本、音频、视频、图片等），而屏蔽其内部复杂的实现细节。 REST是Representational State Transfer的缩写，直译过来就是：表述状态的转移。REST API是一组关于如何构建Web应用程序API的架构规则、标准或指导，或者说REST API是遵循API原则的一种架构风格。REST是专门针对Web应用程序而设计的，其目的在于降低开发的复杂度，提高系统的可伸缩性。下面是设计REST风格的系统架构时需要满足或者遵循的一些基本条件和原则： 1、在REST架构中，Web中所有的事物（文本、音频、视频、图片、链接）都可以被统一的抽象为资源（resource）2、在REST架构中，每一个资源都有与之对应的唯一资源标识符（resource identifier）,当资源的状态发生改变时,资源标识符不会发生改变3、在REST架构中，所有的操作都是无状态的。REST架构遵循CRUD原则，所有的资源都可以通过GET、POST、PUT和DELETE这四种行为完成对应的操作。4、可缓存（可选项），在REST架构中需要缓存来有效的处理大批量的请求5、接口一致 现在，了解了API和REST API的基本概念，那这两者之间有什么异同？如果按照数学上集合的概念来解释API与REST API之间的联系与区别，API是REST API的超集，REST API 是API的子集；所有的REST API都是API，但不是所有的API都是REST API。更通俗的解释是：所有的男人都是人，但不是所有的人都是男人。 2、REST API 与RESTful API 在第一小节中，了解了什么是REST API，接下来聊聊REST API与RESTful API之间的异同。很多初学者很容易将这两者等同起来，认为RESTful API就是REST API，这可能是单纯的从字面上去理解了，当你深入的去了解两者的本质后，你会发现其实不然。REST API是Web API设计的一种规范或者指导原则，而RESTful API则是这中架构设计原则或者规范的一种具体实现方式。也就是说，RESTful API是REST API的非正式实现方式，因为实现REST API的方式有很多，RESTful API只是其中一种，且没有完全满足REST API的所有设计原则，每个开发者在实现REST 架构时的则重点都会有差别。 很多初学者容易将REST API与RESTful API两者的概念搞混淆，我想可能只是看字面意思，而没有关注它们本身的含义（就像认识中文字一样，有边读边，无边读中间，断章取义了）。这就好比很多人会把变性人等同于女人，变性人可能五官的表象看起来和女人一样，但变性人不能生育，它只是满足了定义一个女性的大多数条件（实现），但本质上不是女人。 接下来，通过一个简单的例子以加深对REST API和RESTful API的理解。下面将给出一个执行CURD操作的RESTful API设计案例： 说明：resource代指某种资源的名称，可以时student(学生)、teacher(老师)、book(书籍)等等，通常使用名词来表示；{id}则代指某种资源的唯一标识符（resource identifier）下面是一个具体的小例子，以学生管理为例，设计学生管理的API。学生资源包括ID，姓名和所学课程信息，学生资源信息如下： 现在，我们需要将学生数据保存到数据库，然后执行查询、修改和删除学生数据的操作。学生管理API的使用者调用的API如下： 1、创建学生资源：[POST] http://www.example.com/student2、获取所有学生资源：[GET] http://www.example.com/students3、获取ID=1001的学生资源：[GET] http://www.example.com/studen...4、修改ID=1001的学生资源：[PUT] http://www.example.com/studen...5、删除ID=1001的学生资源：[DELETE] http://www.example.com/studen... 前面的内容说到，API共享数据资源，而屏蔽内部实现，API的使用者（客户端）关注的是资源（读懂数据）,并不需要了解API内部构造;API的提供者（服务端）只关注自己的内部实现，而不关系API使用者（客户端）的状态。为了加深对这一概念的理解，下面给出学生管理API的内部实现示例： ...

翻译：疯狂的技术宅https://medium.freecodecamp.o…本文首发微信公众号：前端先锋欢迎关注，每天都给你推送新鲜的前端技术文章自从 Web 开始迅猛发展，对程序员来说开发 API 是一项很艰巨的任务。我们开发 API 的方式必须随着时间的推移而发展，以便我们始终可以开发良好、直观且设计良好的API。在过去几年中，GraphQL 在越来越受到开发者的欢迎。许多公司已经开始采用这种技术来构建他们的API。 GraphQL 是一种由 Facebook 在 2012 年开发并于 2015 年公开发布的查询语言。它已经收到了广泛的关注，并被许多大公司采用，如 Spotify，Facebook，GitHub，NYTimes，Netflix，沃尔玛等。在本系列教程中，我们将研究 GraphQL，了解它是什么，并学习使这种查询语言如此直观和易用的原因是什么。先让我们研究一下 REST 存在的问题，以及 GraphQL 如何解决它们。我们还将了解那些大公司为什么用 GraphQL 去构建API，以及为什么它是 API 的未来。REST很久以前，当我们把 API 的设计从 SOAP 转向 REST 时，认为此举将会为工作提供更多的灵活性。我们不能否认 REST 的运作是良好的，在当时是一个很好的举措。但是随着应用和 Web 变得越来越复杂，API 也会随着这些变化而发展。不过 REST 也确实存在很多问题。让我们看看它们是什么：太多的端点REST 中的每个资源都由端点表示。因此，在实际的程序中，我们最终会为这些资源提供大量端点。如果要发出 GET 请求，则需要具有特定参数并特定于该请求的端点。如果要发出 POST 请求，则需要该请求的另一个端点。但是这有什么问题呢？假设我们正在开发一个像 Facebook 这样的大型社交媒体应用，最终会得到很多端点，这意味着开发和维护这些 API 将花费更多的时间和精力。过度获取和欠缺的信息真正令人烦恼的问题是通过 REST API 会过度获取和欠缺的信息。这是因为 REST API 会始终返回固定的结构。除非我们再去创建一个特定的端点，否则无法准确获取所需的数据。因此如果我们只需要一小部分数据，就必须处理整个对象。例如，如果我们只需要在 REST API 中获取用户的 firstName，lastName 和 age，就无法在不获取整个对象的情况下得到这些数据。信息欠缺也存在问题。如果我们想从两个不同的资源获取数据，就需要分别对两个不同的端点进行调用。在一个巨大的程序中，扩展性会很差，因为在某些情况下我们只需要获取特定的数据，而不是整个对象。假设我们正在开发一个具有 100 个端点的程序。想象一下工作量和产生的代码量。随着时间的推移，开发会变得越来越困难，代码也难以维护，程序员会感到迷茫。版本控制在我看来，REST 中的一个痛点就是版本控制。使用 REST API，通常会看到许多带有 v1 或 v2 的 API。这些在 GraphQL 中并不需要，因为你可以通过添加或删除类型来改进 API。在GraphQL中，你所需要做的就是写新代码。可以编写新类型、查询和修改，而无需维护其他版本的API。因此你将看不到如下所示具有端点的 GraphQL API：https://example.com/api/v1/users/12312https://example.com/api/v2/users/12312为什么 GraphQL 是未来早在2012年，Facebook 在开发移动应用时面临一个问题，这导致他们开发了 GraphQL。这些问题非常普遍，特别是当我们谈论 RESTful API 设计时。如上所述，这些问题是：表现不佳端点过多过度获取或欠缺数据每当我们要增加或删除某些内容时，需要开发另一个版本API 难以理解考虑到许多概念，Facebook 的开发人员开使用了一种更好的方法来设计 API，后来将其命名为 GraphQL。基本上它是 REST 的替代品，做了很多改进。使用 GraphQL，我们可以获得许多新功能，在构建 API 时为你提供强大的功能。下面让我们一个一个地审视它们：单端点根本没有必要构建很多端点！GraphQL 只需要一个端点，通过它我们可以在单个请求中获得尽可能多的数据。基本上 GraphQL 会将你的所有查询、修改和订阅封装在一个端点中，并供你调用。它改善了你的开发周期，因为你不必向两个不同的资源发出请求来获取数据。此外，当我们开发一个大型的应用时，不必再像 REST 一样获得大量端点和代码。我们只需要获得一个端点，并根据需要开发尽可能多的请求即可。正如我上面所说，“单端点”方法使你的 API 能够自我描述，你不再需要再去构建文档，因为你的程序员已经知道应该如何使用。他们只需查看代码即可了解API。我们稍后会详细了解它（本系列的下一篇教程）。看起来很神奇，但这就是 GraphQL！使用 GraphQL，你只能获取所需的数据没有过度获取或未被充分利用的信息，你只获取自己需的数据。还记得我们最初讨论的性能问题吗？不会再像那样了，因为 GraphQL 提高了 API 的性能，特别是在网络连接速度较慢的情况下。GraphQL 使得开发 API 变得容易并保持一致很多人认为 GraphQL 非常复杂，因为它涉及模式和单个端点。但是你一旦开始用它开发 API，会发现它比你想象的要容易得多。当你开发网站或应用时，“单端点” API 会给你很大帮助。它使你的 API 更加能够自我描述，并且无需为它编写大量的文档。如果你并不是把 JavaScript 作为主要语言，那也不是问题。 GraphQL 是一种查询语言，这意味着你可以使用任何自己熟悉的语言。在编写本教程时，GraphQL 支持的语言已经超过了 12 种。GraphQL 是未来GraphQL 是一种开源查询语言，这意味着社区可以为其做出贡献并对加以改进。当 Facebook 将其发布到社区时，得到了大量的认同。现在随着越来越多的程序员用它构建 API，GraphQL 一直在快速增长。但是也有些人一直在问它是否真的要取代 REST，或者成为构建 API 的新方法。起初，我认为 GraphQL 是一个炒作，仅仅是创建 API 的另一种方式。但是当我开始研究它时，发现 GraphQL 具有为现代应用程序创建 API 所需的基本功能，因为它非常适合现今的技术栈。所以如果我要对你说些什么，我会说：是的，GraphQL的确是API的未来。这就是大公司在它身上押注的原因。在2018年11月，GraphQL 与 Linux Foundation 合作创建了一个 GraphQL Foundation。这种查询语言鼓励其开发人员创建更多的文档、工具和语言支持。这将确保 GraphQL 的稳定、中立和可持续发展的未来。因此这也是将 GraphQL 视为 API 的未来的另一个原因。当然 GraphQL 不会立即取代 REST，因为许多应用仍然在使用它，也不可能在一夜之间重写它们。随着越来越多的公司采用 GraphQL，UX 和 DX 都将得到改进。结论GraphQL 的确是API的未来，我们需要了解更多信息。这就是我决定撰写这一系列教程的原因，这些教程将为我们展示如何用好 GraphQL，先从查询和修改开始，然后是订阅和身份验证。在本系列的下一篇教程中，我将深入研究 GraphQL，展示 GraphQL 如何与类型一起工作，并创建我们的第一个查询和修改。所以请继续关注并希望在下一个教程中见到你！本文首发微信公众号：前端先锋欢迎扫描二维码关注公众号，每天都给你推送新鲜的前端技术文章欢迎继续阅读本专栏其它高赞文章：12个令人惊叹的CSS实验项目必须要会的 50 个React 面试题世界顶级公司的前端面试都问些什么11 个最好的 JavaScript 动态效果库CSS Flexbox 可视化手册从设计者的角度看 React过节很无聊？还是用 JavaScript 写一个脑力小游戏吧！CSS粘性定位是怎样工作的一步步教你用HTML5 SVG实现动画效果程序员30岁前月薪达不到30K，该何去何从14个最好的 JavaScript 数据可视化库8 个给前端的顶级 VS Code 扩展插件Node.js 多线程完全指南把HTML转成PDF的4个方案及实现 ...

前言在网上找了许久的关于REST的资料，发现网上大部分都是说的比较片面，虽然有部分说出了本质，但也没有详细提出，所以在这里记录一下。RESTful是什么首先，维基百科是这样说的：表现层状态转换（REST，英文：Representational State Transfer）是Roy Thomas Fielding博士于2000年在他的博士论文中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络（例如互联网）中互相传递信息这样的概念有点难以理解，了解一个东西，通常可以先了解他的背景，他是为了解决什么问题而出现的？ Fielding是一个非常重要的人，他是HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。而下面则是他在论文中提出REST的目的。“本文研究计算机科学两大前沿—-软件和网络—-的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。“这段话比较绕口，总结一下，就是REST是一个为了进一步解耦client和server的架构风格。REST风格首先，根据论文可以得知，REST风格是由约束来定义的Web 架构背后的设计基本原理，能够被描述为由一组应用于架构中元素之上的约束组成的架构风格。当将每个约束添加到进化中的风格时，会产生一些影响。通过检查这些影响，我们就能够识别出 Web 的约束所导致的属性。然后就能够应用额外的约束来形成一种新的架构风格，这种风格能够更好地反映出现代 Web 架构所期待的属性。client-servetclient-server之间的解耦，服务提供者和服务消费者互不影响，也是我们常说的前后端分离。前后端分离的优势是比较显著的，改善了用户接口跨多个平台的可移植性；同时通过简化服务器组件，改善了系统的可伸缩性。无状态这个约束使架构拥有了可见性、可靠性和可伸缩性等三个架构属性。 可见性是指能单独的理解一个请求，可靠性是减轻了从局部故障中恢复的任务量， 可伸缩性是指为不必在多个请求之间保 存状态，从而允许服务器组件迅速释放资源。可缓存优势明显，不赘述。统一接口它强调组件之间要有 一个统一的接口。通过在组件接口上应用通用性的软件工程原则，整体的系统架 构得到了简化，交互的可见性（通过方法名即知道动作）也得到了改善。实现与它们所提供的服务是解耦的，这促进了独立的可进化性。然而，付出的代价是，统一接口降低了效率，因为信息都使用标准化的形 式来转移，而不能使用特定于应用的需求的形式。（只能使用put post delete get patch等）解决方法：为需要的动作增加一个 endpoint，使用 POST 来执行动作，比如 POST /resend 重新发送邮件。分层系统分层系统风格通过限制组件的行为（即，每个组件只 能“看到”与其交互的紧邻层），将架构分解为若干等级的层。通过将组件对系统的知识限 制在单一层内，为整个系统的复杂性设置了边界，并且提高了底层独立性。我们能够使用层来封装遗留的服务，使新的服务免受遗留客户端的影响，通过将不常用的功能转移到一个共享的中间组件中，从而简化组件的实现。中间组件还能够通过支持跨多个网络和处理器的负 载均衡，来改善系统的可伸缩性。也就是说服务器和客户端之间的中间层（代理，网关等）代替服务器对客户端的请求进行回应，而客户端不需要关心与它交互的组件之外的事情。按需加载代码通过下载并执行 applet 形式或脚本形式的代码，REST允许对客户端的功能进行扩展。通过减少必须被预先实现的功能的数目，简化了客户端的开发。允许在部署之后下载功能代 码也改善了系统的可扩展性。然而，这也降低了可见性，因此它只是REST的一个可选的约束。设计原则（GITHUB API）了解了REST是什么东西后，我们才能设计出合适的API，以下是根据GITHUB API来总结的（基本参考自：https://cizixs.com/2016/12/12…）使用https这个和 Restful API 本身没有很大的关系，但是对于增加网站的安全是非常重要的。API地址和版本如果 API 变化比较大，可以把 API 设计为子域名，比如 https://api.github.com/v3响应内容尽量使用JSON，JSON在多种语言中支持，如果需要使用其他的如XML， 应该在请求头部 Accept 中指定以资源为中心资源分为单个文档和集合，尽量使用复数来表示资源，单个资源通过添加id或者name等来表示。一个资源可以有多个不同的 URL。资源可以嵌套，通过类似目录路径的方式来表示，以体现它们之间的关系。/users/:username/repos/users/:org/repos/repos/:owner/:repo/repos/:owner/:repo/tags/repos/:owner/:repo/branches/:branch使用正确的METHOD这个比较容易理解，即get（获取），post（创建），put（替换），patch（局部更新），delete（删除），head（获取某个资源的头部信息。比如只想了解某个文件的大小，某个资源的修改日期等）对于不符合CURD的情况，可以采用参数协助如分页page=2&per_page=100：指定第几页，以及每页的记录数，或者增加一个endpoint，如上面说的重发邮件，或者将动作转换为资源（Github:比如“喜欢”一个 gist，就增加一个 /gists/:id/star 子资源，然后对其进行操作：“喜欢”使用 PUT /gists/:id/star，“取消喜欢”使用 DELETE /gists/:id/star）状态码https://developer.mozilla.org…2XX：请求正常处理并返回3XX：重定向，请求的资源位置发生变化4XX：客户端发送的请求有错误5XX：服务器端错误错误处理返回错误时，在响应内容里加上具体的错误信息。Hypermedia API当服务端修改API时，客户端不需要知道和修改。 验证和授权， OAUTH2等限流， 参考githubhttps://developer.github.com/… 对用户的请求限流之后，要有方法告诉用户它的请求使用情况，Github API 使用的三个相关的头部：X-RateLimit-Limit: 用户每个小时允许发送请求的最大值X-RateLimit-Remaining：当前时间窗口剩下的可用请求数目X-RateLimit-Rest: 时间窗口重置的时候，到这个时间点可用的请求数量就会变成 X-RateLimit-Limit 的值编写清晰的文档REST与http的关系？个人理解是REST是一种架构风格，而http则是这种架构实现下的一种协议。比较（以操作为中心）以操作为中心可见性低，即不够清晰。在除了CURD的接口外，以操作为中心调用效率高，不需要hack。以操作为中心没有HyperMidea Api，修改api效率低，需要客户端服务端同时修改。以操作为中心上手难度系数大。以资源为中心，简单数据操作，无事务处理，开发和调用简单， 以操作为中心，清晰的规范标准定义，能够处理较为复杂的面向活动的服务在通常的软件开发过程中，我们常常需要分析达成某个目标所需要使用的业务逻辑，并为业务逻辑的执行提供一系列运行接口。在一些Web服务中，这些接口常常表达了某个动作，如将商品放入购物车，提交订单等。这一系列动作组合在一起就可以组成完成目标所需要执行的业务逻辑。在需要调用这些接口的时候，软件开发人员需要向这些接口所在的URL发送一个请求，从而驱使服务执行该动作

了解RESTREST（Representational State Transfer）由Roy Fielding于2000年在他的博士论文中引入和定义，REST是用于设计分布式系统的架构风格，它不是标准，而是一组约束，例如无状态，具有客户端/服务器关系和统一接口，REST与HTTP并不严格相关，但最常与它相关联。REST原则资源公开易于理解的目录结构URI。表示传输JSON或XML以表示数据对象和属性。消息显式使用HTTP方法（例如，GET、POST、PUT和DELETE）。无状态交互在请求之间不在服务器上存储客户端上下文，状态依赖性限制和限制可伸缩性，客户端保持会话状态。HTTP方法使用HTTP方法将CRUD（创建、检索、更新、删除）操作映射到HTTP请求。GET检索信息，GET请求必须是安全且幂等的，这意味着无论使用相同参数重复多少次，结果都是相同的，它们可能有副作用，但用户不期望它们，因此它们对系统的操作不是至关重要的，请求也可以是部分的或有条件的。检索ID为1的地址：GET /addresses/1POST请求URI上的资源对提供的实体执行某些操作，POST通常用于创建新实体，但也可用于更新实体。创建一个新地址：POST /addressesPUT将实体存储在URI中，PUT可以创建新实体或更新现有实体，PUT请求是幂等的，幂等性是PUT与POST请求的期望之间的主要区别。修改ID为1的地址：PUT /addresses/1注意：PUT替换现有实体，如果仅提供数据元素的子集，则其余数据元素将替换为空或null。PATCH仅更新URI上实体的指定字段，PATCH请求既不安全也不是幂等（RFC 5789），这是因为PATCH操作无法确保整个资源已更新。PATCH /addresses/1DELETE请求删除资源，但是，不必立即删除资源，它可能是异步或长时间运行的请求。删除ID为1的地址：DELETE /addresses/1HTTP状态码状态码表明HTTP请求的结果。1XX — 信息2XX — 成功3XX — 重定向4XX — 客户端错误5XX — 服务器错误媒体类型Accept和Content-Type HTTP头可用于描述HTTP请求中发送或请求的内容，如果客户端正在请求JSON格式的响应，则可以将Accept设置为application/json，相反，在发送数据时，将Content-Type设置为application/xml会告诉客户端请求中发送的数据是XML。