rest软件架构

什么是REST 表述性状态转移，分布式超媒体软件的一种 架构风格 是一套简单的设计原则、一种架构风格（或模式），不是一种具体的标准和架构。 资源 任何事物，只要有被引用的必要，就是一个资源（resource）。它可以是一个事物，也可以是一个抽象的概念。 万物皆资源 ` REST约束和风格 URL表示资源 CRUD操作 状态表示转移 无状态服务 Http状态码 Cache控制 Proxy REST核心是构架以资源为核心的模型 REST关键原则 为所有的资源定义ID 将所有资源链接在一起 使用标准方法 资源多重表示 无状态通信（服务器是无状态的） 为所有资源定义ID URI:URI构成了一个全局命名空间，是有URI标识你的关键资源意味着它们获得了一个唯一、全局的ID。 总结：无论WEB中的资源代表单一的数据项、数据项集合、虚拟亦或实际的对象还是计算结果等，都可以使用URI标识。 什么是RESTful 符合REST约束风格和原则的应用程序或设计就是RESTful Token认证机制 RESTful提供的API是无状态的，即下一次调用请求与当前的调用请求是完全无关的，但这就是无法保证系统资源的安全性。 Token机制（令牌机制）就是用来解决无状态和安全性之间的矛盾。原理如下： 用户发送用户名和密码（一般密码加密），请求验证通过； 服务器判断用户名和密码是否正确 来源： https:/

1.什么是Web Service（Web服务） 从表面上看， Web Service 就是一个应用程序，它向外界暴露出一个能够通过 Web 进行调用的 API 。 这就是说，你能够用编程的方法透明的调用这个应用程序，不需要了解 它的任何细节， 跟你使用的编程语言也没有关系。 例如可以创建一个提供天气预报的 Web Service ，那么无论你用哪种编程语言开发的应用，都可以通过调用它的 API 并传入城市信息来获得该城市的天气预报。 之所以称之为 Web Service ，是因为它基于 HTTP 协议 传输数据， 这使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集 成 。 2.SOA（Service-Oriented Architecture，面向服务的架构） SOA 是一种思想，它将应用程序的不同功能单元通过中立的契约联系起 来， 独立于硬件平台、操作系统和编程语言，使得各种形式的功能单元能够更好的集成 。 显然， Web Service 是 SOA 的一种 较好 的解决方案 ， 它更多的是 一种标准 ，而 不是 一种 具体的技术 。 3. 概念解释：SOAP、WSDL、UDDI SOAP 简单对象访问协议（ S imple O bject A ccess P rotocol ）， 是 Web Service 中交换数据的一种协议规范

写这篇文章是目的不是介绍Web-Service, 而是从Restful Web Service说起来剖析一下 什么才 是真正的Restful Style的架构与协议，从而更好的理解web服务的设计理念与架 构本质。 一：Web Service基础知识 一个最简单web服务就一个web页面等待请求与处理。更容易理解的方式是Web Service 可以把一个应用变成一个基本WEB方式的请求与处理的应用。常见的两种 Web Service处理 方式为： a. 基于WSDL/SOAP的方式 b. Rest方式 方式a是比较正统的，客户端调用必须先取得WSDL文件，然后生成调用的API才可 以使用。 它不是我要说的重点，基本调用流程如下： 方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操作分 别为： GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。 POST – 增加信息内容，显示以前的信息内容，可以看作是insert操作 PUT – 更新信息内容，相当与update DELETE – 删除信息内容可以看作是delete Rest方式更加简单便捷，如果从设计原则上看HTTP协议本身已经是最Restful风格的 协议了 HTTP协议很好的支持了CRUD的操作。正是因为如此，WEB2.0以来, 基于 Restful的Web

标签: WCF , RESTful RESTful服务使用的是成为具象状态传输（Representational State Transfer, REST）的体系结构风格 了解REST体系结构 体系结构风格是一组可在执行构建时应用的约束。软件的体系结构风格会对功能做出说明，这些功能用于指导建立软件系统。REST 这一体系结构风格所构建的软件供客户端（用户代理）请求服务（端点）之用。REST 是实现客户端/服务器体系结构风格的一种途径——REST 实际上是明确构建在客户端/服务器体系结构风格之上的。 REST 这一术语最早是由 Roy Thomas Fielding 在他的博士论文（“体系结构风格和基于网络软件体系的设计”）中提出的。他当时参与制订的规范对于今天的互联网起到了巨大的推进作用，这个规范就是：超文本传输协议 (HTTP)。一般来讲，体系结构风格描述人的背景与风格讨论并无干系，但这一观点在此并不适用，因为我认为能对 REST 产生基本了解的最佳途径之一是思索 Web 及其工作方式。 我必须假定您作为开发人员对 Web 很熟悉，或者可能象我一样，每天都使用 Web 或对其痴迷。事实证明，Web 在任何时候皆可视为最大、伸缩性最强且最流行的分布式应用程序。REST 的约束采用的就是掌控 Web 的基本原则。这些原则是： 用户代理与资源交互，任何可命名和表达的事物都可称为资源

一、Soap和Rest的定义 　　SOAP（Simple Object Access Protocol 简单对象访问协议），用于在Web Service中把远程调用和返回封装成机器可读的格式化数据，事实上SOAP使用XML数据格式，以描述调用的远程过程、参数、返回值和出错信息等等。其实SOAP最早是针对RPC的一种解 决方案，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高，而且随着需求的增长，又不得增加协议以支持安全性， 这使SOAP变得异常庞大，背离了简单的初衷。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。SOAP 常常被称作“web services”，这是一个误称。SOAP 和 web 基本上说不上话。REST 提供的才是真正的基于 URL 和 HTTP 的 “web services”。 REST(Representational State Transfort表述性状态传递)形式上应该表述为客户端通过申请资源来实现状态的转换，在这个角度系统可以看成一台虚拟的状态机。按照REST原则设计的软件、体系结构，通常被称为“REST式的”（RESTful），抛开R. T.

目录 什么是RESTful架构？ REST 架构原则 资源（Resource） 表现层（Representation） 状态转换（State Transfer） 无状态通信原则 什么是RESTful架构？ RESTful 架构，是目前最流行的一种互联网软件架构。它 基于REST原则 ，结构清晰、符合标准、易于理解、扩展方便，正得到越来越多网站的采用。 在传统上，软件和网络是两个不同的领域，很少有交集；软件开发主要针对单机环境，网络则主要研究系统之间的通信。互联网的兴起，使得这两个领域开始融合，越来越多的人开始意识到， 网站即软件 ，而且是一种新型的软件。 2000年， Roy Thomas Fielding （HTTP 协议的主要设计者、Apache 基金会的第一任主席）在他的博士论文中提出了【REST】这一概念；对于论文的写作目的，他有如下的描述： 我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。 Fielding将他对互联网软件的架构原则，定名为 REST，即 Representational State Transfer 的缩写。这里对这个词组的翻译是「表现层状态转化」。 如果一个架构符合REST原则，就称它为 RESTful 架构 ；也就是说，只要我们弄清楚了

文章讲的不错，更具体一些，对实践的指导意义更强 原文： https://www.infoq.cn/article/rest-introduction/ 不知你是否意识到，围绕着什么才是实现异构的应用到应用通信的“正确”方式，一场争论正进行的如火如荼：虽然当前主流的方式明显地集中在基于 SOAP、WSDL 和 WS-* 规范的 Web Services 领域，但也有少数人用细小但洪亮的声音主张说更好的方式是 REST，表述性状态转移（REpresentational State Transfer）的简称。在本文中，我不会涉及争论的话题，而是尝试对 REST 和 RESTful HTTP 应用集成做实用性的介绍。以我的经验，有些话题一旦触及就会引来众多的讨论，当涉及到这方面话题的时候，我会深入详细地阐述。 REST 关键原则 大部分对 REST 的介绍是以其正式的定义和背景作为开场的。但这儿且先按下不表，我先提出一个简单扼要的定义：REST 定义了应该如何正确地使用（这和大多数人的实际使用方式有很大不同）Web 标准，例如 HTTP 和 URI。如果你在设计应用程序时能坚持 REST 原则，那就预示着你将会得到一个使用了优质 Web 架构（这将让你受益）的系统。总之，五条关键原则列举如下： 为所有“事物”定义 ID 将所有事物链接在一起 使用标准方法 资源多重表述 无状态通信

（转载自 https://blog.csdn.net/weixin_37539378/article/details/79956760 ） 一、前言 ”前后端分离“已经成为互联网项目开发的业界标杆，通过Tomcat+Ngnix(也可以中间有个Node.js)，有效地进行解耦。并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。 前后端分离(解耦)的核心思想是：前端Html页面通过Ajax调用后端的RestFul API并使用Json数据进行交互。 注： 【在互联网架构中，web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。 应用服务器：一般指像tomcat，jetty，resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。】 一般只有Web服务器才能被外网访问，应用服务器只能内网访问。 二、为什么前后端分离 一般公司后端开发人员直接兼顾前端的工作，一边实现API接口，一边开发页面，两者互相切换着做，而且根据不同的url动态拼接页面，这也导致后台的开发压力大大增加。前后端工作分配不均。不仅仅开发效率慢，而且代码难以维护。而前后端分离的话，则可以很好的解决前后端分工不均的问题，将更多的交互逻辑分配给前端来处理