格式
-
登录信息为可选字段
-
#
表示片段- 指向HTML文档中的特定图片或和章节
- 可以通过
${URL}#ch1
让打开的窗口正中对准ch1一节,而不是最上方
- 可以通过
- HTTP服务器通常只处理整个对象,片段一般不单独传送
- 浏览器获得整个资源后根据片段显示部分资源
- 指向HTML文档中的特定图片或和章节
字符编码
-
URL中只能出现安全字符和保留字符
- 他字符均需要经过编码之后才能出现在URL中
-
安全字符
- US-ASCII字符集中可以显示的字符
- 对于安全字符,编码和不编码是等价的
- 包含
A-Z
,a-z
,1-9
以及-_.~
-
保留字符
- 在URL中具有特定意义的字符,用于分割URL为不同部分
- 本身允许出现在URL中,但是如果在参数或者路径中出现保留字符,则必须编码
- 以免和保留字符原有含义产生歧义
- 包含
:/?#[]@!$&'()*+,;=
-
不安全字符
- 在URL中没有特殊含义,但在URL所在的上下文中可能具有特殊意义的字符
- 例子
在传输,用户排版或者文本处理程序处理过程中,都有可能引入无关紧要的空格,或者将那些有意义的空格给去掉
<>
通常用于在普通文本中起到分隔Url的作用
- 编码(转义)方式
- URL编码通常也被称为百分号编码
- 使用%百分号加上两位代表该字节16进制形式的字符
- URL编码通常也被称为百分号编码
- 对于空格的两种编码方式
- 空格被编码成加号
+
的情况只会在查询字符串(?
之后)部分出现 - 而被编码成
%20
则可以出现在路径和查询字符串中 - 原因:https://www.cnblogs.com/skychx/p/http-space-to-what.html
- 空格被编码成加号
RESTful风格
-
URL只用于定位资源,而用HTTP动词(GET,POST,DELETE,DETC)描述操作
- GET获取资源
- POST新建和更新资源
- PUT更新资源
- DELETE删除资源
-
禁止在URL中使用动词
- Bad style
GET /getProducts
- Good style
GET /products
获取所有商品POST /products
增加商品
- Bad style
-
GET和HEAD方法不应该改变资源状态
- 禁止操作:
GET /deleteProducts?id=1
- 禁止操作:
-
资源地址使用嵌套结构
GET /students
- 获得所有学生信息
GET /students/001/address
- 获得学号为001的学生的地址
PUT /students/001//address/city
- 更新该学生的城市地址
-
无状态
- 一次调用一般就会返回结果,不存在类似于打开连接-访问数据-关闭连接这种依赖于上一次调用的情况
-
通常的含Query参数的URL风格以操作为中心,而Restful风格的URL以资源为中心
- 资源不一定限制于文本,图片等,也可以是一种动作, 例如转账
- Bad style
POST /accounts/1/transfer/500/to/2
- Good style
POST /transaction
- Body:
from=1&to=27amount=500
- Bad style
- 以操作为中心的坏处
- 操作之间是会有关联,你的设计容易变成“第2个操作要求第1个操作进行过”,这种关系多起来你的系统就乱了
- 你的URL设计会缺乏一致性
- 以资源为中心的好处
- 能够利用Cache机制来提高性能?
- 各个资源虽然可能有关联,但依旧是能够简单地切掉这些关联导致相互独立的,所以不会有非常乱的耦合性
- URL具有很强可读性的,具有自描述性
- REST 把 url 里的动词都去掉了,资源对象只剩下有限的几种行为,这样不同的人更容易设计出差不多的东西,别人看你设计的东西,需要的解释也更少
- 资源不一定限制于文本,图片等,也可以是一种动作, 例如转账
-
REST风格的难点
- 像转账,登录等操作如何资源化
- 无状态操作如何处理有状态操作
-
适用情况
- 基于资源型的RESTFul API 接口粒度和返回结果过于的“粗”,它通常返回的都是完整的数据模型,这对于客户端非常不友好
- 对于开放的API,豆瓣、新浪微博、GitHub,好用;对于内部开发,不好用
- 但开放API之所以开放,就是因为它不知道你到底需要什么返回结果
- 内部开发由于需求非常明确,通常来说服务器是不应该简单粗暴的直接甩资源实体给客户端的
-
参考