restful接口是什么,如何理解rest和restful，什么是restfulAPI？

restful接口是什么,如何理解rest和restful，什么是restfulAPI？详细介绍

本文目录一览： restful api接口规范是什么？

REST（REpresentationStateTransfer）描述了一个架构样式的网络系统，比如web应用程序。
一般依赖于HTTP认证，HTTP认证有几种：basic，digest，token，这些都有标准的实现的开源包需要主要的是这个认证的帐号跟你业务的帐户实际是不一样的。REST属于webService一种，安全是后台服务的安全，因此不需要实际的业务帐号，通常是系统keyStore证书库里的账户。
RESTFUL特点包括：
1、每一个URI代表1种资源。
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
3、通过操作资源的表现形式来操作资源。
4、资源的表现形式是XML或者HTML。
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

什么是Restful API

1、不使用url参数：
传统API设计：/api/list?pageIndex=2
Restful API设计：/api/list/2
2、用method表示操作类型
传统API设计：

Restful API设计：

3、传统API设计：把每个url当做一个功能
Restful API设计：把每个url当做一个唯一的资源

简单说Restful API就是API的规范。
目的：
1、为了实现前后端分离。
2、减少沟通成本，让API通俗易懂，提高API的可读性。
3、多端公用一套接口
在 REST 架构风格中，每一个 URI 代表一种资源。因此，URI 是每一个资源的地址的唯一资源定位符。所谓资源，实际上就是一个信息实体，它可以是服务器上的一段文本、一个文件、一张图片、一首歌曲，或者是一种服务。RESTful API 规定了通过 GET、 POST、 PUT、 PATCH、 DELETE 等方式对服务端的资源进行操作。

http://www.ruanyifeng.com/blog/2014/05/restful_api.html

如何理解rest和restful，什么是restfulAPI？

简单理解一
就是用URL定位资源，用HTTP描述操作。
简单理解二
URL定位资源，用HTTP动词(GET,POST,DELETE,DETC)描述操作。
官方定义
一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
以web开发举例
在设计web接口的时候，REST主要是用于定义接口名，接口名一般是用名次写，不用动词，那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型来区分。
比如，我们有一个students接口，对于“学生”我们有增删改查四种操作，怎么定义REST接口？
增加一个学生，uri: http://testcode.com/school/students 接口类型：POST
删除一个朋友，uri: http://testcode.com/school/students 接口类型：DELETE
修改一个朋友，uri: http://testcode.com/school/students 接口类型：PUT
查找朋友，uri: http://testcode.com/school/students 接口类型：GET
上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词students，都是通过Http请求的接口类型来判断是什么业务操作。
举个反例
uri: http://testcode.com/school/addStudents 该接口用来表示增加学生，这就是不符合REST协议的接口。
建议
用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。(反例：传统web开发返回的状态码一律都是200，其实不可取。)
REST风格接口意义
前后端分离。前端拿到数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，在web，ios，android三端都可以用相同的接口，节约开发成本以及便于同一调试。

什么是REST以及 RESTful？

image image 本文由 黑壳博客 转载
本文来源 什么是REST以及 RESTful?？
imagepng imagepng 自从Roy Fielding博士在2000年他的博士论文中提出 REST （Representational State Transfer）风格的软件架构模式后，REST就基本上迅速取代了复杂而笨重的SOAP，成为Web API的标准了。
什么是Web API呢？
如果我们想要获取某个电商网站的某个商品，输入 http://localhost:9999/products/123 ，就可以看到id为123的商品页面，但这个结果是HTML页面，它同时混合包含了Product的数据和Product的展示两个部分。对于用户来说，阅读起来没有问题，但是，如果机器读取，就很难从HTML中解析出Product的数据。
如果一个URL返回的不是HTML，而是机器能直接解析的数据，这个URL就可以看成是一个Web API。比如，读取 http://localhost:9999/api/products/123 ，如果能直接返回Product的数据，那么机器就可以直接读取。
REST就是一种设计API的模式。最常用的数据格式是JSON。由于JSON能直接被JavaScript读取，所以，以JSON格式编写的REST风格的API具有简单、易读、易用的特点。
编写API有什么好处呢？由于API就是把Web App的功能全部封装了，所以，通过API操作数据，可以极大地把前端和后端的代码隔离，使得后端代码易于测试，前端代码编写更简单。
此外，如果我们把前端页面看作是一种用于展示的客户端，那么API就是为客户端提供数据、操作数据的接口。这种设计可以获得极高的扩展性。例如，当用户需要在手机上购买商品时，只需要开发针对iOS和Android的两个客户端，通过客户端访问API，就可以完成通过浏览器页面提供的功能，而后端代码基本无需改动。
当一个Web应用以API的形式对外提供功能时，整个应用的结构就扩展为：
REST-arch REST-arch 把网页视为一种客户端，是REST架构可扩展的一个关键。
** 网络上的所有事物都被抽象为资源**
** 每个资源都有一个唯一的资源标识符**
** 同一个资源具有多种表现形式(xml,json等)**
** 对资源的各种操作不会改变资源标识符**
** 所有的操作都是无状态的**
** 符合REST原则的架构方式即可称为RESTful**
REST主要对以下两方面进行了规范
-定位资源的URL风格，例如
http://bhusk.com/admin/1234
http://bhusk.com/admin/1234/10/11
-如何对资源操作
采用HTTP协议规定的GET、POST、PUT、DELETE动作处理资源的增删该查操作
image image 对应的中文是rest式的;Restful web service是一种常见的rest的应用,是遵守了rest风格的web服务;rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构).
符合REST约束风格和原则的应用程序或设计就是RESTful.
- Spring MVC 对 RESTful应用提供了以下支持
- 利用@RequestMapping 指定要处理请求的URI模板和HTTP请求的动作类型
- 利用@PathVariable讲URI请求模板中的变量映射到处理方法参数上
- 利用Ajax,在客户端发出PUT、DELETE动作的请求
** 可以采用Ajax方式发送PUT和DELETE请求**
采用RESTful架构后，需要将web.xml中控制器拦截的请求设置为/，这样会将css,js等静态资源进行拦截，发送404错误。
解决方法：
本篇文章参考了一部分 http://t.cn/RuZZUK3 ， http://t.cn/RKO0YPr
程序员是个辛苦的职业
请善待你们身边的每一位程序员~
欢迎在评论写下你的程序员趣事，程序员不是一个死板的职业~~
欢迎扫描二维码加入我们的小组织 ，大家都叫我壳叔，很期待你的到来。 黑壳网交流群 Q 群: 200408242
11a84075a304ac57f6d37323512fd24cde9836350b9d80148b282eeaa188b196c2358d4ffd7006cbpng 11a84075a304ac57f6d37323512fd24cde9836350b9d80148b282eeaa188b196c2358d4ffd7006cbpng

restful接口和普通接口的区别

REST种架构风格其核面向资源REST专门针中国络应用设计发式降低发复杂性提高系统伸缩性REST提设计概念准则： 一.中国络所事物都抽象资源(resource) 二.每资源都唯资源标识(resource identifier)资源操作改变些标识 三.所操作都状态 REST简化发其架构遵循CRUD原则该原则告诉我于资源(包括中国络资源)需要四种行：创建获取更新删除完相关操作处理您通统资源标识符（Universal Resource IdentifierURI）识别定位资源并且针些资源执行操作通 HTTP 规范定义其核操作GET,PUT,POST,DELETE 由于REST强制所操作都必须stateless没文约束做布式集群都需要考虑文保持问题极提高系统伸缩性 于SOAP WebserviceRestful Webservice选择问题首先需要理解SOAP偏向于面向严格规范标准包括安全事务等各面内容同SOAP强调操作操作象离WSDL文件规范XSD文件别其定义REST强调面向资源要我要操作象抽象资源即使用REST架构风格 REST ful 应用问题 否使用REST需要考虑资源本身抽象识别否困难本身简单类似增删改查业务操作抽象资源比较容易于复杂业务抽象资源并简单事情比校验用户等级转账事务处理等些往往并容易简单抽象资源 其严格规范标准定义要求且前期规范标准需要指导业务系统集发候SOAP风格由于清晰规范标准定义明显优势我始实现前严格定义相关接口接口传输数据 简单数据操作事务处理发调用简单些使用REST架构风格优势于较复杂面向服务我使用REST候都仍传统面向思想通转换工具再转换REST服务种使用式没意义 效率易用性 SOAP协议于消息体消息都定义同消息扩展性各种互联中国标准提供扩展基础WS-*系列较功规范由于SOAP由于各种需求断扩充其本身协议内容导致SOAP处理面性能所降同易用性面及习本所增加 REST重视其实面其高效及简洁易用特性种高效面源于其面向资源接口设计及操作抽象简化发者良设计同限度利用Http初应用协议设计理念同我看REST吸引发者能够融合前Web二.0前端技术提高发效率例型中国站放REST风格API都种返形式除传统xml作数据承载（JSON,RSS,ATOM）等形式中国站前端发员说能够mashup各种资源信息 安全性 技术没坏合适种技术思想误用反效RESTSOAP各自都自优点同些场景改造REST其实走向SOAP（例安全） REST于资源型服务接口说合适同特别适合于效率要求高于安全要求高场景SOAP熟性给需要提供给发语言于安全性要求较高接口设计带便利所我觉纯粹说设计模式占据主导位没意义关键看应用场景 同重要点要扭曲REST现中国站都跟风发REST风格接口其实都其形知其弄伦类性能安全保证 熟度 SOAP虽发展现已经脱离初衷于异构环境服务发布调用及厂商支持都已经达较熟情况同平台发语言间通SOAP交互web service都能够较互通 由于没类似于SOAP权威性协议作规范REST实现各种协议仅仅能算私协议需要遵循REST思想细节面太没约束REST发展所走向规范直接影响部设计否能够命

restful api接口规范

restful api接口规范如下：
1、协议
API与用户的通信协议，总是使用HTTPs协议。
2、域名
应该尽量将API部署在专用域名之下。
如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。
3、版本（Versioning）
应该将API的版本号放入URL。
另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。Github采用这种做法。
4、路径（Endpoint）
路径又称"终点"（endpoint），表示API的具体网址。
在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的"集合"（collection），所以API中的名词也应该使用复数。
举例来说，有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样。

什么是restful风格的api
一个好的RESTfulAPI，具备特征

一个好的RESTfulAPI，应该具备以下特征：
这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。
1.浏览器是最常见和最通用的REST客户端。好的RESTfulAPI应该能够使用浏览器HTML完成所有的测试（不需要使用编程语言）。这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTfulAPI的功能组合起来，建造Mashup类的应用。
这个API中所包含的资源和对于资源的操作，应该是直观和容易理解的，并且符合HTTP协议的要求。
REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTfulAPI的核心内容。RESTfulAPI建模的过程与面向对象建模类似，是以名词为核心的。这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。而HTTP协议并不是一种传输协议，它实际提供了一个操作资源的统一接口。对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTfulAPI建模的过程，可以看作是具有统一接口约束的面向对象建模过程。
按照HTTP协议的规定，GET方法是安全且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法），PUT、DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。
2.如果发现资源上的操作过多，以至于HTTP的方法不够用，应该考虑设计出更多的资源。设计出更多资源（以及相应的URI）对于RESTfulAPI来说并没有什么害处。
这个API应该是松耦合的。
RESTfulAPI的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。正是这三个层次确保了RESTfulAPI的松耦合性。
3.当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。感兴趣的读者可以参考《REST实战》。
这个API中所使用的表述格式应该是常见的通用格式
在RESTfulAPI中，对于资源的操作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。
4.这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。所以除非有很合理的要求，通常不需要使用自定义的私有格式。
使用HTTP响应状态代码来表达各种出错情况
HTTP响应状态代码，是HTTP协议这个统一接口中用来表达出错情况的标准机制。响应状态代码分成两部分：statuscode和reasonphase。两部分都是可定制的，也可以使用标准的statuscode，只定制reasonphase。
5.如果一个所谓的“RESTfulAPI”对于任何请求都返回200OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保操作语义的可见性”这个REST架构风格的基本要求。
这个API应该对于HTTP缓存是友好的
6.充分利用好HTTP缓存是RESTfulAPI可伸缩性的根本。HTTP协议是一个分层的架构，从两端的useragent到originserver之间，可以插入很多中间组件。而在整个HTTP通信链条的很多位置，都可以设置缓存。HTTP协议内建有很好的缓存机制，可以分成过期模型和验证模型两套缓存机制。如果API设计者完全没有考虑过如何利用HTTP缓存，那么这个API的可伸缩性会有很多问题。

什么是RESTful

先看REST是什么意思，英文Representational state transfer 表述性状态转移 其实就是对 资源 的表述性状态转移。
简单的说：RESTful是一种架构的规范与约束、原则，符合这种规范的架构就是RESTful架构。

资源的地址 在web中就是URL （统一资源标识符）
资源是REST系统的核心概念。 所有的设计都是以资源为中心

结合项目怎么识别资源
1.商品加入购物车 购物车
2.提交订单 订单
3.创建用户 用户

围绕资源进行 添加，获取，修改，删除，以及对符合特定条件的资源进行列表操作 。针对资源设计接口

RESTful 架构的核心规范与约束：统一接口
分为四个子约束：
1.每个资源都拥有一个资源标识，每个资源的资源标识可以用来唯一地标明该资源
2.消息的自描述性
3.资源的自描述性。
4.HATEOAS Hypermedia As The Engine Of Application State(超媒体作为应用状态引擎)
即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作

目的：实现客户端无需借助任何文档即能调用到所有的服务器资源

三、资源的URL设计
1.通过URL来表示资源
资源分为主资源与子资源
因为主资源是一类独立的资源 所以主资源应直接放在相对路径下：例如
若要表示主资源的实例：如果实例的ID=1，则这样表示： /goods/1
子资源：
一个实例的子资源可能是一个集合也可能是一个单一的子资源
子资源为图片集合：/goods/1/pictures
子资源为商品折扣的单子子资源：/goods/1/discount
2.单数 vs. 复数
获取用户1的信息，哪种方式更符合RESTful?
/api/users/1
/api/user/1
3.相对路径 vs. 请求参数
极光的RESTful API:
获取用户信息 GET /v1/users/{username} 参数放在路径中
VS
获取用户信息 GET /v1/users?username=xxxxx 拼接的方式

获取应用管理员列表 GET /v1/admins?start={start}&count={count} ？后拼接参数的方式：这种方式一般作为过滤资源

4.使用合适的动词 get delete put post

选择请求接口的方式： get delete
PUT 在服务器更新资源（客户端提供改变后的完整资源）。
POST 在服务器新建一个资源

5.使用标准的状态码
GET

hello world!!!