restful

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 l 基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。 l 不适应于所有的项目，当项目比较小时使用RestFul架构，项目变得更复杂； l RESTful架构将服务器分成前端服务器和后端服务器两部分，前端服务器为用户提供无模型视图；后端服务器为前端服务器提供接口。浏览器向前端服务器请求视图，通过视图中包含的AJAX函数发起接口请求获取模型。 l RESTful架构时对MVC架构改进后形成的一种架构，通过使用事先定义好的接口与不同的服务联系起来。在REST’ful架构中，浏览器使用POST，DELETE，PUT，GET四种请求方式分别对指定的URL资源进行增删改查操作。因此，RESTful是通过URI实现对资源的管理及访问，具有扩展性强、结构清晰的特点。 GET：获取资源、POST：新建资源、PUT：更新资源、DELETE：删除资源 每一个URI代表一种资源，资源的表现形式是XML或者HTML，通过操作资源的表现形式来操作资源。 客户端和服务器之间的交互在请求之间是无状态的，从客户端到服务器端的每个请求都必须包含理解请求所必须的信息。 Restful特点包括： 1、每一个URI代表1种资源； 2、客户端使用GET、POST、PUT

简介 Representational State Transfer 简称 REST 描述了一个架构样式的网络系统。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 概念: 资源（Resources） REST是”表现层状态转化”，其实它省略了主语。”表现层”其实指的是”资源”的”表现层”。那么什么是资源呢？就是我们平常上网访问的一张图片、一个文档、一个视频等。这些资源我们通过URI来定位，也就是一个URI表示一个资源。 表现层（Representation） 资源是做一个具体的实体信息，他可以有多种的展现方式。而把实体展现出来就是表现层，例如一个txt文本信息，他可以输出成html、json、xml等格式，一个图片他可以jpg、png等方式展现，这个就是表现层的意思。 URI确定一个资源，但是如何确定它的具体表现形式呢？应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对”表现层”的描述。 状态转化（State Transfer）访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，肯定涉及到数据和状态的变化。而HTTP协议是无状态的，那么这些状态肯定保存在服务器端，所以如果客户端想要通知服务器端改变数据和状态的变化，肯定要通过某种方式来通知它。 URI格式规范

0. API设计满足关键点 API应当基于 web 标准来设计 API应当对开发者友好并且便于在浏览器地址栏中浏览和探索 API应当是简单、直观和一致的，使它用起来方便和舒适 API应当是高效的，同时要维持和其他需求之间的平衡 1. API命名 1.1 根地址 好的RESTful API要基于HTTPS来发布 API规模不大时，在域名后面增加 api 目录，如： https://www.trawe.cn/api/ API规模很大时，使用以api开头的二级域名，如： https://api.trawe.cn/ 1.2 版本问题 新版本尽量对旧版本作兼容 版本信息放在URL中 https://api.trawe.cn/v1.2/users/123 协议报文中增加version字段 { version: "1.0", .... .... } HTTP Header中增加版本信息 使用已的HTTPHeader：Accept Header：Accept: application/json+v1.2 自定义 Header： X-Api-Version: 1.2 1.3 端点设计原则 1) 命名 CRUD操作一律使用名词，不使用动词 url一律使用小写字母 url命名方式不使用 camel方式，采用 - 连接两个单词，如：app-setups，而不是appSetups 请求参数命名方式使用

网址： Building a RESTful Web Service 目标 ：使用Spring创建 “Hello, World” RESTful web服务 步骤 ： Step 1 使用 Spring Initializr 创建应用 build.gradle修改依赖 implementation 'org.springframework.boot:spring-boot-starter-web' Step 2 Model 模型 package com . example . restservice ; public class Greeting { private final long id ; private final String content ; public Greeting ( long id , String content ) { this . id = id ; this . content = content ; } public long getId ( ) { return id ; } public String getContent ( ) { return content ; } } Step 3 Controller 控制器 package com . example . restservice ; import java . util .

概述 REST（英文： Representational State Transfer ，简称 REST ）描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。 在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。 值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。 原则条件 REST 指的是一组架构 约束条件 和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合 云计算 之类的环境。客户端可以缓存数据以改进性能。 在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI

简介 2000 年，Roy Thomas Fielding 博士在他那篇著名的博士论文《Architectural Styles and the Design of Network-based Software Architectures》中提出了几种软件应用的架构风格，REST 作为其中的一种架构风格在这篇论文的第5章中进行了概括性的介绍。 REST 是“REpresentational State Transfer”的缩写，可以翻译成“表现状态转换”，但是在绝大多数场合中我们只说 REST 或者 RESTful。Fielding 在论文中将 REST 定位为“分布式超媒体应用（Distributed Hypermedia System）”的架构风格，它在文中提到一个名为“HATEOAS（Hypermedia as the engine of application state）”的概念。 我们利用一个面向最终用户的 Web 应用来对这个概念进行简单阐述：这里所谓的应用状态（Application State）表示 Web 应用的客户端的状态，简单起见可以理解为会话状态。资源在浏览器中以超媒体的形式呈现，通过点击超媒体中的链接可以获取其它相关的资源或者对当前资源进行相应的处理，获取的资源或者针对资源处理的响应同样以超媒体的形式再次呈现在浏览器上。由此可见

是什么？解决了哪些问题 JSON Web Token，看名字就知道是什么了。 和session相比不用在server端保存一个连接客户端的会话 没有将生成的token保存到server端，所以即使每次请求是不同的服务端，也可以运行，实现了分布式。 原理 JSON Web Token结构 结构： xxxx.yyyy.zzzzz Header Header包含两部分：1、token的类型，这里是JWT，2、所使用的hash算法（HMAC SHA256 或者 RSA） { "alg": "HS256", "typ": "JWT" } 然后Base64加密 Payload 主要包含三类声明： 预保留的声明(Reserved claims)，这类推荐但是不强制使用，包括： iss (issuer), exp (expiration time), sub (subject), aud (audience), and others 公共声明(Public claims),这类可以添加任何信息但不建议添加敏感信息。 私有声明（Private claims），消费者和提供者之间共享的信息表明双方可以使用它们。 例如 { "sub": "1234567890", "name": "John Doe", "admin": true } 然后Base64加密 Signature

如何更好地设计RESTful API? 目前对于大多数项目来说， 前后端分离，接口调用， RESTful API使用越来越流行。但是如何设计更好，更容易让人理解的API还是需要下一番功夫的。 下面我将介绍如果更好地设计RESTful API。 一，使用名词而非动词 为了方便理解， 我们应该为所有的API列表使用名词。 例如 订单 GET POST PUT DELETE /cars 获取所有的汽车列表 新建一辆汽车 批量修改 删除所有 /cars/112 获取特定的汽车 NOT ALLOWED（405） 修改特定的汽车 删除特定的汽车 不用使用如下： /getAllCars /createNewCar /deleteAllRedCars 二， GET 方法不应该修改任何的状态 如果需要修改相关数据项的状态, 用 PUT , POST 或者 DELETE 而非 GET 例如： 不要使用 GET /users/113?activate or GET /users/113/activate 三， 使用复数名词 不要把单数和复数名字搞混淆了， 一般来讲， 所有的资源都使用复数， 例如： /cars 而非 /car /users 而非 /user /products 而非 /product /settings 而非 /setting 四，使用子资源 如果两个方法中间有必然的关系，

Spring Boot is an opinionated framework that simplifies the development of Spring applications. It frees us from the slavery of complex configuration files and helps us to create standalone Spring applications that don’t need an external servlet container. This sounds almost too good to be true, but Spring Boot can really do all this . This blog post demonstrates how easy it is to implement a REST API that provides CRUD operations for todo entries that are saved to MongoDB database. Let’s start by creating our Maven project. Note: This blog post assumes that you have already installed the

RPC 即远程过程调用（Remote Procedure Call Protocol，简称RPC），像调用本地服务(方法)一样调用服务器的服务(方法)。通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式. RPC是分布式架构的核心，按响应方式分如下两种： 同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作 异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。 同步调用的实现方式有WebService和RMI。Web Service提供的服务是基于web容器的，底层使用http协议，因而适合不同语言异构系统间的调用。RMI实际上是Java语言的RPC实现，允许方法返回 Java 对象以及基本数据类型，适合用于JAVA语言构建的不同系统间的调用。 异步调用的JAVA实现版就是JMS(Java Message Service)，目前开源的的JMS中间件有Apache社区的ActiveMQ、Kafka消息中间件，另外有阿里的RocketMQ。 RPC架构里包含如下4个组件: 1、 客户端(Client)：服务调用方 2、 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方 3、 服务端存根(Server Stub)