restful

Restful levels： 要知道API的哪个级别，Richardson引入了一个名为 Richardson Maturity Model的模型 。正如名称本身所暗示的，它讲述了REST API的成熟度级别。 根据Richardson成熟度模型，任何REST API都属于从0级到3级的任何成熟度级别，如下所述。 开发的每个REST API都不必高达3级。但是这个模型可以帮助REST API的开发人员知道他们的API属于哪个级别，以及如何通过在上面的模型层次结构中向上移动来改善他们的API 。 0级：POX的沼泽 在此级别设计的API根本不是Rest API，而是基于SOAP的Web服务发生的地方。 在此级别，没有基于资源的URI， 超媒体的概念，也没有正确使用HTTP协议 （这是REST API的关键特性）。实际上，属于此级别的API不会充分利用或利用HTTP协议的全部潜力。HTTP仅被视为传输层协议或仅仅是客户端和服务器之间的隧道机制。 第1级：基于资源的地址/ URI 这是REST API的起始级别。在这个层面上，概念的资源基础地址被 引入，它告诉你应该有个人的URI服务器上的每个资源（不像LEVEL 0，我们有一个单一的URI从客户端的每个传入的请求）。 这就像减少了从单个端点（处理所有操作的LEVEL 0端点）到多个基于资源的URI（如Divide and

摘要 什么Rest？ REST即表述性状态传递（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。 表述性状态转移是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML（标准通用标记语言下的一个子集）以及HTML（标准通用标记语言下的一个应用）这些现有的广泛流行的协议和标准。REST 通常使用 JSON 数据格式。 Http方法和RESTful Web Services REST基本架构使用的http方法有以下四种：GET(用于查询数据)、PUT（修改数据）、DELETE(删除数据)、POST（添加数据）。 Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。 基于 REST 架构的 Web Services 即是 RESTful。 由于轻量级以及通过 HTTP 直接传输数据的特性，Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言（比如 Java 程序

概述： 　　 　　REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，Roy Fielding是 HTTP 规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。 原则条件： 　　REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 　　RESTful的实现： RESTful Web 服务的 Java 框架； RESTful Web 服务与 RPC 样式的 Web 服务；构建 RESTful Web 服务的多层架构。 　　 RESTful 的成熟度模型： Level 0 利用 HTTP 协议做数据交换，所有的参数描述通过 url 或者 POST body 形式通知服务器，返回相应的数据，此级别通常都是基于 。实质上就是基于 HTTP 的 RPC（远程过程调用）

　　REST 是 Representational state transfer 的缩写，翻译过来的意思是表达性状态转换。REST 是一种架构风格，它包含了一个分布式超文本系统中对于组件、连接器和数据的约束。REST 是作为互联网自身架构的抽象而出现的，其关键在于所定义的架构上的各种约束。只有满足这些约束，才能称之为符合 REST 架构风格 。 Levles： 第一个层次（Level 0）的 Web 服务只是使用 HTTP 作为传输方式，实际上只是远程方法调用（RPC）的一种具体形式。SOAP 和 XML-RPC 都属于此类。 第二个层次（Level 1）的 Web 服务引入了资源的概念。每个资源有对应的标识符和表达。 第三个层次（Level 2）的 Web 服务使用不同的 HTTP 方法来进行不同的操作，并且使用 HTTP 状态码来表示不同的结果。如 HTTP GET 方法来获取资源，HTTP DELETE 方法来删除资源。 第四个层次（Level 3）的 Web 服务使用 HATEOAS。在资源的表达中包含了链接信息。客户端可以根据链接来发现可以执行的动作。 　　HATEOAS（Hypermedia as the engine of application state）是 REST 架构风格中最复杂的约束，也是构建成熟 REST 服务的核心

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为： 1.网络上的 所有事物都可以被抽象为资源(resource) 2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识 3.所有的操作都是 无状态 的 REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。 其核心操作只有GET,PUT,POST,DELETE。 由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。 对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源

　　首先，应该怀着这样一种心态来学习Restful——Restful你可以将其理解一种软件架构风格，并且诠释了Http协议的设计初衷，所以不要把他理解的那么神秘，Restful风格有好处，当然也是有坏处的。 　　然后是正文（转的）： 在SOA的基础技术实现方式中WebService占据了很重要的地位，通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受，同时各大网站不断开放API提供给开发者，也激起了REST风格WebService的热潮。 SOAP 什么是SOAP，我想不用多说，google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。 REST REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子

REST是一种架构风格，其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为： 1.网络上的所有事物都可以被抽象为资源(resource) 2.每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识 3.所有的操作都是无状态的 REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,PUT,POST,DELETE。 由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。 对于SOAP Webservice和Restful Webservice的选择问题，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源

RESTful是用于前台和后端进行通信的一种规范或者说一种风格，采用的是HTTP和HTTPS协议，数据传输的格式使用的都是JSON，而不是XML。通常，RESTful的URL中只有名词，没有动词，而且名词在复数的情况就应该使用其复数的形式。网上有专门讲解RESTful的详细教程，本文只是Flask中用于实现RESTful规范的插件Flask-RESTful的学习笔记，就不详细介绍RESTful了。 安装：pip install Flask-RESTful 使用场景： 一般来说，如果URL是用于向前台返回json数据，就可以考虑使用这个RESTful插件了。 RESTful基础使用 RESTful的使用重点在视图类的定义，包括请求方法的定义，基础使用步骤如下，具体参见示例代码： 导入： from flask_restful import Api, Resource 创建Api对象： api = Api(app) 创建视图类： 视图类需要继承Resource，然后定义对应的请求方法即可，返回值为json格式数据，即字典 添加url： 使用`api.add_resource`方法添加url相关信息，第一个参数为视图类的名称，第二个参数是url字符串，并且可以有多个url，第三个参数是endpoint等关键字参数。 简单示例： from flask import Flask, url

知乎上的一个通俗易懂的解释：如何给老婆解释什么是RESTful - 柳树的文章 - 知乎 https://zhuanlan.zhihu.com/p/30396391 阮一峰大佬的restful设计指南： http://www.ruanyifeng.com/blog/2014/05/restful_api.html#comment-text 来源： https://www.cnblogs.com/huahongzhenghexiu/p/12512675.html

越来越多的人开始意识到，网站即软件，而且是一种新型的软件。 　　这种“互联网软件”采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。 　　网站开发，完全可以采用软件开发的模式。但是传统上，软件和网络是两个不同的领域，很少有交集；软件开发主要针对单机环境，网络则主要研究系统之前的通信。互联网的兴起，使得这两个领域开始融合，现在我们必须考虑，如何开发在互联网环境中使用的软件。 　　RESTFUL架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以得到越来越多网站的采用。 　　但是，到底什么是RESTFUL架构，并不是一个容易说清楚的问题。下面，我就谈谈我理解的RESTFUL架构。 　　一、起源 　　REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。 　　 　　Fielding是一个非常重要的人，它是HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。所以，他的这篇论文已经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。 　　他这样介绍论文的写作目的： 　　"本文研究计算机科学两大前沿----软件和网络----的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化