侧边栏壁纸
博主头像
枕头下放双臭袜子博主等级

今我何功德,曾不事农桑

  • 累计撰写 163 篇文章
  • 累计创建 30 个标签
  • 累计收到 0 条评论

Restful API是什么?有什么特点?

枕头下放双臭袜子
2022-05-16 / 0 评论 / 0 点赞 / 52 阅读 / 2,807 字 / 正在检测是否收录...

本篇文章转载自API 是什麼? RESTful API 又是什麼?

API 是什么?

API,全名 Application Programming Interface (应用程式介面),简单来说,是品牌开发出的一种接口,让第三方可以额外开发、应用在自身的产品上的系统沟通介面。

来看个清楚直白的叙述影片:API 就是你的餐厅服务生

以实际应用的范例而言,Google Map API 就很好理解了,常常可以在各式不同的网站看见 Google Map 应用,很多都是接 Google Map API 的范例,营运考量上,有可能 API 会限制一定使用流量以内免费,超过即收费,Google map 也是如此。

HTTP:

在 RESTful API 之前,要再理解一下 HTTP,HTTP 是一种协议,全名 Hypertext Transfer Protocol(超文本传输协议),网路世界其实就分为客户端、服务器端,举例说,客户端就是我电脑浏览器,服务器端就是 Baidu,我要看 Baidu 的首页,就是向 Baidu 的服务器端传送了这个要求,Baidu 再回应资源给我。为了让要求和回应统一规范,就有了 HTTP。

再举例,假设我要吃卤味:

在浏览器输入 Baidu 网址,按下 enter,送出 request (跟老板说我要切两块百页豆腐)
服务器端收到 request 检查该网址是否存在(老板转身看百页豆腐还有没有)
服务器端发送 response 回来(百页豆腐切好了)
跟老板点餐的方式,有一定的规范跟方式,像是我一定要用语言来讲出来的,不可以用比划的,我要说中文,不可以说英文,这就是 HTTP 协定。

如果服务器端发现网址不存在(老板发现百页豆腐卖完了),就会回传 HTTP status code 状态码 404:

状态码又会再分为下几种:

2xx = Success(成功)
3xx = Redirect(重定向)
4xx = User error(客户端错误)
5xx = Server error(服务器端错误)

在 HTTP 中,会有很多种 method 做为请求的方法,常用的几个动作分别为:GET / POST / PUT / DELETE,正好会对应到资料库基本操作 CRUD 增删查改。

CRUD 为 Create(新增)、Read(读取)、Update(更新)与Delete(删除)的缩写

RESTful API:

那 RESTful API 又是什么? 先来看是谁发明的吧

Roy Thomas Fielding,他是HTTP协议(1.0版和1.1版)的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席,REST这个词是他在2000年的博士论文中提出的。

REST,全名 Representational State Transfer( 表现层状态转移),它是一种设计风格,RESTful 只是转为形容词,像是 peace 和平这名词,转成形容词是 peaceful,RESTful 则形容以此规范设计的 API,称为 RESTful API

先用白话来说,以刚刚 API 影片中的餐厅服务生为例,如果使用一般的 API 点菜,我要加点菜、查看已点菜色、修改已点菜色、取消已点菜色,都需要不同的服务生替我服务,可能加点的服务生是 John、查看已点菜色是 Annie….等,RESTful API,就是让这些动作,都可以由同一位服务生完成。

RESTful API 主要由三种元件组成:

Nouns 名词:定义资源位置的 URL,每个资源在网路上都会有唯一的位置,就如每户人家都有唯一的地址一样。

Verbs 动词:对资源要做的动作。

Content Types 资源呈现方式:API 资源可以以多种方式表现,最常用的是 JSON,较轻,也较好处理。

一般的 API,可能会是这样:

获得资料GET /getData

新增资料POST /createData

删除资料DELETE /deleteData/1

不同公司,不一样的工程师,设计的名称都会不一样,没有统一的命名方式,造成在引用各家 API 时,都需要详读 API 文件,理解所有设计命名规则后,才可使用。

若以 RESTful API 风格开发的话:

获得资料GET /data

新增资料POST /data

删除资料DELETE /data/1

就是用一个唯一的 URL 定位资源,将动作藏在 HTTP 的 method 里面

RESTful API 优点:

所以使用 RESTful 风格设计的 API,就有了以下几种优点及限制:

1. 有唯一的URL表示资源位置,统一的 API 接口。(Uniform Interface)

2. 无状态。(Stateless)

RESTful 的状态,意即 HTTP 的请求状态,一般 Web 服务中,Server 端和 Client 端交互的资讯,会存在 Server 端的 Session (例如:已登入状态),在 Client 端再次发送请求的时候,Server 端透过保存在 Server 端的 Session,去执行 request。无状态的意思,即 Client 端自行保存状态,在请求 Server 的时候,一併附上给 Server 端,Server 端无保存 Client 端的状态资讯。

举例来说,可能在用户登录系统时,Server 产生 token 纪录 user 已登录系统,然后把 token 还给 Client,在 Client 再次发送请求的时候,把 token 一起发给 Server,这样 Server 就知道这一个 Client 是已经处于登录的状态。

意即所有的资源都可以 URI 定位,而且这个定位与其他资源无关,也不会因为其他资源的变化而变化,资源相互的依赖性降低。

举一个白话一点的例子:查询员工工资:
第一步:登录系统。

第二步:进入查询工资的页面。

第三步:搜索该员工。

第四步:点击姓名查看工资。

这样的操作流程就是有状态的,查询工资的每一个步骤都依赖于前一个步骤,只要前置操作不成功,后续操作就无法执行。如果输入一个URL就可以直接得到指定员工的工资,这种情况就是无状态的,因为获取工资不依赖于其他资源或状态,这种情况下,员工工资是一个资源,由一个 URL 与之对应可以通过 HTTP 中的 GET 方法得到资源,这就是典型的 RESTful 风格。

3. 可更高效利用快取来提高回应速度 (Cachable)

在 server-side,GET 过的资源,如果没有被变更过,可以利用 cache 机制减少 request。
在 client-side,透过 client 端 cache 纪录 cache 版本,若向 server 要求资源时发现 server 最新版与 cache 相同,则 client 端直接取用本地资源即可,不需要再做一次查询

4. 分层系统架构 (Layered System)

5. 客户端服务器分离 (Client-Server)

6. 充份利用 HTTP protocal(GET/POST/PUT/DELETE) (Manipulation of resources through representations)

7. 可执行程式码的设计,像是 JavaScript(非必要实作项目) Code-On-Demand (optional)

0

评论