目录
RESTful API是一种设计风格，用于构建可扩展、易于维护和互操作的网络应用程序。它基于HTTP协议，通过对资源进行操作来实现应用程序的功能。以下是关于RESTful API的一些重要概念：
资源：在RESTful API中，资源是应用程序中可访问的一切事物，如用户、产品、订单等。
URI：每个资源都有一个唯一的标识符，称为URI（统一资源标识符）。通过URI，可以定位和访问资源。
HTTP方法：RESTful API使用HTTP方法来定义对资源的操作。常用的HTTP方法有GET（获取资源）、POST（创建资源）、PUT（更新资源）和DELETE（删除资源）。
状态码：每个HTTP响应都包含一个状态码，用于指示请求的处理结果。常见的状态码有200（成功）、201（创建成功）、400（请求错误）和404（资源不存在）。
使用RESTful API构建Web应用程序的步骤如下：
设计资源：首先确定应用程序中的资源，并为每个资源定义URI。
定义资源的操作：为每个资源定义可以执行的操作，并为每个操作选择合适的HTTP方法。
实现API端点：在服务器端实现API端点，处理来自客户端的请求，并根据请求的方法和URI执行相应的操作。
处理请求和响应：在API端点中处理请求参数，并通过HTTP响应返回结果。可以使用JSON或XML等格式来传输数据。
身份验证和授权：在API中实现身份验证和授权机制，以确保只有授权的用户才能访问受限资源。
文档和版本控制：编写API文档，描述每个资源的URI、操作和参数。还可以考虑使用版本控制来管理API的变化。
测试和部署：在开发过程中进行API的单元测试和集成测试，并最终部署到生产环境中。
通过使用RESTful API，可以将应用程序的功能暴露给外部开发人员和其他应用程序。它提供了一种灵活和可扩展的方式，使不同的系统能够相互交流和共享数据。
以下将以这两个规则为基础，描述如何构造一个符合?REST?规范的请求。
?/api/getUser （用来获取某个用户的信息，还需要以参数方式传入用户 id 信息）??
??/api/updateUser （用来更新用户信息）??
可能在更新用户不同信息时，提供不同的接口，比如：
??/api/updateUserName??
??/api/updateUserEmail??
??/api/updateUser??
??/api/deleteUser （用来删除单个用户）??
??/api/resetUser （重置用户的信息）以上三种情况的弊端在于：首先加上了动词，肯定是使?URL?更长了；其次对一个资源实体进行不同的操作就是一个不同的?URL，造成?URL?过多难以管理。??
?以GET?和?POST为主，在?REST?架构中，有以下几个重要的请求方法：GET，POST，PUT，PATCH，DELETE可以适当在对应场景下使用
http(s): ? ?//{server.com }/{app-name..} /{version} /{domain} /{rest-convention}
接口版本号可以省略
(例如：安全-允许指定的用户可以访问这个区域)或者业务上的原因(例如：同样的功能在同一个前缀之下。)
单资源(?singular-resourceX?)
????????rl样例：order?(order即指那个单独的资源X)
????????GET?–?返回一个新的order
????????POST-?创建一个新的order，从post请求携带的内容获取值。
单资源带id(singular-resourceX/{id}?)
????????URL样例：order/1?(查询?order即指那个单独的资源X?)
????????GET?–?返回id是1的order
????????URL样例：order/remove/1?(查询?order即指那个单独的资源X?)
????????GET?–?返回bool
????????URL样例：order/modify/1?(查询?order即指那个单独的资源X?)
????????POST?–?返回bool
复数资源(plural-resourceX/)
????????URL样例:orders/
????????GET?–?返回所有orders
????????URL样例：orders/search?name=123
????????GET?–?返回所有满足查询条件的order资源。(实例查询，无关联)?–?order名字等于123的。
复数资源查找(plural-resourceX/searchByXXX)
????????URL样例：orders/searchByItems?name=ipad
????????GET?–?将返回所有满足自定义查询的orders?–?获取所有与items名字是ipad相关联的orders。
????????URL样例：order/1/items?(这里order即为资源X，items是复数资源Y)
????????GET?–?将返回所有与order?id?是1关联的items。
singular-resourceX/{id}/singular-resourceY
????????URL样例：order/1/item
????????GET?–?返回一个瞬时的新的与order?id是1关联的item实例。
????????POST?–?创建一个与order?id?是1关联的item实例。Item的值从post请求体中获取。
singular-resourceX/{id}/singular-resourceY{id}/singular-resourceZ
????????URL样例：order/1/item/2/package
????????GET?–?返回一个瞬时的新的与item2和order1关联的package实例。
????????POST?–?创建一个新的与item?2和order1关联的package实例，package的值从post请求体中获得。
上面的规则可以再继续递归下去，并且复数资源后面永远不会再跟随复数资源。
总结几个关键点，用来更清晰地表述规则。
在使用复数资源的时候，返回的是最后一个复数资源使用的实例。
在使用单个资源的时候，返回的是最后一个单数资源使用的实例。
查询的时候，返回的是最后一个复数实体使用的实例(们)。
一些其他规范：
规则1：URI结尾不应包含（/）
规则2：正斜杠分隔符（/）必须用来指示层级关系
规则3：应使用连字符（?-?）来提高URI的可读性
规则4：不得在URI中使用下划线（_）
规则5：URI路径中全都使用小写字母