RESTful API 架构解读

首先我们还是先介绍下 RESTful api 的来龙去脉。 首先, RESTful (下文都简称 RESTful api 为 RESTful )

1、RESTful 这个概念最早是在 2000年 Roy Thomas Fielding 博士在他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》 中提出了几种软件应用的架构风格,REST作为其中的一种架构风格在这篇论文的第5章中进行了概括性的介绍。 (其实我很好奇,为何国内的开发者们没能做出这些 标准通用级别的 规范)

这里 我们需要理解的就是 RESTful 它不是一种 类似于 http/https 的规范,而是一种 web 的架构。 而 RESTful 架构风格主要包含了 

1)采用 URI 标识资源
2)用 '链接' 关联相关的资源
3)使用标准的 http 方法
4)支持多种资源表示方式
5)无状态性 接下来,就用着五点 继续往下介绍。

一、采用 URI 标识资源

首先 标识资源 中的 资源 指的是什么?
在任何 在客户端能够访问到的 任何形式(图片、文字、音频、视频等)的 事物均可以理解为资源。
同时, 存储在数据库中的数据也可以理解为资源。
并且 通过 uri 标识以后,任何在客户端能够访问到的资源 均有一个或者多个标识。 然后 我们通过 uri 访问静态资源,访问数据库请求后返回的数据等等。例如: https://vuejs.com.cn/#/use/start/1 (当前id=1的用户信息)
https://vuejs.com.cn/#/use/resource/2017/09 (2017年九月份所有留言信息)
https://vuejs.com.cn/#/base/color/2017 (2017新增用户) 这样 一个简单的 uri 就具备了很强的标志性 和 可读性。除此之外 uri 还能够比较清晰的获取到静态资源路径。 所以站在 存在即为合理的角度来思考的话,既然该 uri 存在,那么此 uri 必须是 标识某个资源而存在。

二、用 '链接' 关联相关的资源

这里的  ‘链接’ 就是我们常常说的 url, url 和上面说到的 uri有什么区别呢?

恩,说到这里,我们就来详细的介绍下 uri、url、urn 三者之间的关系和区别。

uri (uniform resource identifier 统一资源标识符)
url (uniform resource locator 统一资源定位器)
urn (uniform resource name 统一资源命名) 也就是说,URI是以一种抽象的,高层次概念定义统一资源标识,而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。 介绍完 url 下面就说到访问一个页面, 页面中可能存在 文字、图片、视频等文件展示。 这里就是关联了相关资源。一个 url 关联了 图片、文字、视频 这三个资源。

三、使用标准的 http 方法

这里标准的用法, 概括起来包含了 这7种

GET (从服务器取出资源)
POST (在服务器新建一个资源)
PUT (在服务器更新资源(客户端提供改变后的完整资源))
PATCH (在服务器更新资源(客户端提供改变的属性))
DELETE (从服务器删除资源) HEAD (获取资源的元数据)
OPTIONS (获取信息,关于资源的哪些属性是客户端可以改变的) 后面二种 为不常用方法。 GET 方法相信大家都很熟悉了。 这里解释一下 POST 和 PUT 方法。虽然 通过发送POST和PUT请求均可以添加一个新的资源,但是两者的不同之处在于:对于前者,请求着一般不能确定标识添加资源最终采用的URI,即服务端最终为成功添加的资源指定URI;对于后者,最终标识添加资源的URI是可以由请求者控制的。也正是因为这个原因,如果发送PUT请求,我们一般直接将标识添加资源的URI作为请求的URI;对于POST请求来说,其URI一般是标识添加资源存放容器的URI。
简单点说就是 post 方法 可以将要新增的 资源 放在 data 中而不一定非得放在 uri 中。 而 put 方法新增资源的时候,资源必须放在 uri 中。 这就是 使用标准 http 方法中的 方法, 在日常的开发过程中 最常用的就是 post 和 get 方法了。当然了 post 和 get 方法也是有很大区别来的。 区别呢? 分为2点: 1) get 请求需要将 请求所带参数放在请求的 url 中。 而 post 需要将 请求所带参数放在 http 包的包体中。
2)get 方法提交数据最大只能是 1024 字节。 而 post 理论上是没有上限的。 好了~ http 方法相关的内容就这么多。

四、支持多种资源表示方式

这里的 多种资源表示方式需要解释下, 资源 和 资源的表示 是两个意思。 资源是一个笼统的概念, 资源的表示方式 则为 具体的 资源内容呈现方法。

这里就是需要说明一下 在 请求返回 其实返回的不是资源  而是 资源的表现形式。

五、无状态性

RESTful只要维护资源的状态,而不需要维护客户端的状态。对于它来说,每次请求都是全新的,它只需要针对本次请求作相应的操作,不需要将本次请求的相关信息记录下来以便用于后续来自相同客户端请求的处理。

这里可以理解为 RESTful 的 Web 上展示的任何信息均为通过 资源获取的方式来获得。 所以任何状态值都是通过 请求返回 回来的。

so~ 今天先到这里。 如有错误欢迎指正。

RESTful API 架构解读的更多相关文章

  1. 深入理解 RESTful Api 架构

    转自https://mengkang.net/620.html 一些常见的误解 不要以为 RESTful Api  就是设计得像便于 SEO 的伪静态,例如一个 Api 的 URL 类似于 http: ...

  2. RESTful api架构设计

    阮老师的这两篇文章足够了 理解 RESTful 架构 RESTful API 设计指南

  3. Restful API 架构与设计参考原则

    1. 什么是RESTREST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移. 它首次出现在2000年Roy Fielding的博 ...

  4. SpringBoot RESTful API 架构风格实践

    如果你要问 Spring Boot 做什么最厉害,我想答案就在本章标题 RESTful API 简称 REST API . 本项目源码下载 1 RESTful API 概述 1.1 什么是 RESTf ...

  5. RESTful API架构和oauth2.0认证机制(概念版)

    1. 什么是REST REST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移. 它首次出现在2000年Roy Fielding的 ...

  6. (转载https://segmentfault.com/a/1190000016313947)了解RestFul Api架构风格设计

    最近几年REST API越来越流行,特别是随着微服务的概念被广泛接受和应用,很多Web Service都使用了REST API. REST是HTTP规范主要编写者之一的Roy Fielding提出的, ...

  7. RESTful API URI 设计: 查询(Query)和标识(Identify)

    相关文章:RESTful API URI 设计的一些总结. 问题场景:删除一个资源(Resources),URI 该如何设计? 应用示例:删除名称为 iPhone 6 的产品. 是不是感觉很简单呢?根 ...

  8. 移动互联网实战--Web Restful API设计和基础架构

    前言: 在移动互联网的大潮中, Web Restful API逐渐成为Web Server重要的一个分支. 移动端和服务端的交互, 主流的方式还是通过Http协议的形式来进行. 请求以Get/Post ...

  9. RESTful架构解读

    什么是REST REST与技术无关,代表的是一种软件架构风格.REST全称是Representational State Tranfer, 表征性状态转移. REST从资源的角度类审视整个网络,它将分 ...

随机推荐

  1. outlook 无法搜索邮件的解决方法

    我的outlook版本是2007 SP3,英文版.一直有搜索不到邮件的问题,例如在搜索框输入发件人的名字,或者邮件中的词语,就是搜索不到邮件,即使那封邮件确实存在. 在网上搜索,Microsoft 的 ...

  2. 1001.A+B Format (20)代码自查(补足版)

    1001.A+B Format (20)代码自查(补足版) 谢谢畅畅酱的提醒,发现了代码中的不足,把变量名更改成更合理的名字,并且把注释也换成英文啦! 栋哥提供的代码自查的方式也帮助了我发现很多代码中 ...

  3. 团队作业8——Beta 阶段冲刺4th day

    团队作业8--Beta 阶段冲刺4rd day 一.当天站立式会议   二.每个人的工作 (1)昨天已完成的工作(具体在表格中) 添加了支付功能,并且对支付功能进行了测试 (2)今天计划完成的工作(具 ...

  4. 团队作业10——Beta版本事后诸葛亮

    事后诸葛亮分析 1.总结的提纲内容: a. 项目管理之事后诸葛亮会议. 一.设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件要解决的是教师需要 ...

  5. 线程高级篇-读写锁ReentrantReadWriteLock

    转载原文:http://blog.csdn.net/john8169/article/details/53228016 读写锁: 分为读锁和写锁,多个读锁不互斥,读锁和写锁互斥,这是有JVM自己控制的 ...

  6. 201521123064 《Java程序设计》第6周学习总结

    1. 本章学习总结 1.1 面向对象学习暂告一段落,请使用思维导图,以封装.继承.多态为核心概念画一张思维导图,对面向对象思想进行一个总结. 注1:关键词与内容不求多,但概念之间的联系要清晰,内容覆盖 ...

  7. 201521044091《java程序设计》第四次总结

    1. 本周学习总结 1.1 尝试使用思维导图总结有关继承的知识点. 1.11.2 使用常规方法总结其他上课内容 Object是所有对象类的父类,而toString方法只有可以转换为字符串的类型对象才可 ...

  8. 201521123028 《Java程序设计》第3周学习总结

    1. 本周学习总结 2. 书面作业 Q1.代码阅读 public class Test1 { private int i = 1;//这行不能修改 private static int j = 2; ...

  9. JSP学习(一)之中文乱码问题的解决

    一.响应中的乱码 我们所看到的页面,是由服务器把内容放入响应(response)中,然后发送给浏览器的.如果响应中的数据无法被正常解析,就会出现中文乱码.为什么英文不存在乱码问题?因为无论是ISO-8 ...

  10. 201621123067《JAVA程序设计》第一周学习总结

    第一周-JAVA基本概念 1.本周学习总结 本周初次接触Java这一工程语言,我也首次接触了类名和面向对象这两个关键术语,虽然有C的基础但还是觉得有点不同.同时也学习到了Java的安装,eclipse ...