网上整理的对于Rest和Restful api的理解

一、什么是Rest?

REST不是"rest"这个单词,而是几个单词缩写 -- REpresentational State Transfer 直接翻译:表现层状态转移,但这个翻译正常人根本看不懂,找到的一种最好理解的说法是,URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。

二、Restful api接口有什么特征?

REST描述的是在网络中client和server的一种交互形式;REST本身不实用,实用的是如何设计 RESTful API(REST风格的网络接口)。

1.URL的根路径

http://api.chesxs.com/v1

2.需要有api版本信息

http://api.chesxs.com/v1

3.URL中只使用名词指定资源,不用动词,且推荐使用复数

服务(Server)提供的RESTful API中,URL中只使用名词来指定资源,原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。比如:

http://api.chesxs.com/v1/cars // 获取某个账户下的车辆列表
http://api.chesxs.com/v1/fences // 获取某个账户下的围栏列表

4. 用HTTP协议里的动词来实现资源的添加,修改,删除等操作。即通过HTTP动词来实现资源的状态扭转

GET 用来获取资源,
POST 用来新建资源(也可以用于更新资源)。比如:POST http://api.chesxs.com/v1/car: 添加车辆
PUT 用来更新资源,
DELETE 用来删除资源。比如:DELETE http://api.chesxs.com/v1/cars 删除某辆车 (在http parameter指定好友id) UPDATE http://api.chesxs.com/v1/fence 更新围栏信息 

错误使用: GET http://api.chesxs.com/v1/deleteCar 删除车辆

5.GET应该是安全的,不会改变资源状态

这个应该很好理解,get的时候就只是获取资源,而不涉及添加、更新、删除资源。

6.使用正确的HTTP Status Code返回状态码

常用的有404,200,500,400等等。

总结,看一个标准的restful api要可以做到

看Url就知道要操作的资源是什么,是操作车辆还是围栏
看Http Method就知道操作动作是什么,是添加(post)还是删除(delete)
看Http Status Code就知道操作结果如何,是成功(200)还是内部错误(500)
时间: 2024-07-30 00:19:32

网上整理的对于Rest和Restful api的理解的相关文章

说说自己对RESTful API的理解s

REST不是英文上的rest单词,其英文缩写为presentational State Transfer ,直译为表现状态转移,咋看起来很学术,不懂,其实不用去死抠这个词的意思.REST是一种约束和架构(设计),符合这个风格的都算API.如果实在想了解REST ,直接看提出REST的那篇论文. 知乎上有句话总结的很好了,URL定位资源用HTTP动词(GET POST DELETE)描述操作. 其实只要理解以下几个原则就可以了: 1.提供资源定位 一般在计算机系统中,client和server通信

RESTful API 设计最佳实践(转)

摘要:目前互联网上充斥着大量的关于RESTful API(为了方便,以后API和RESTful API 一个意思)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API格式如何?你的API是否应该加入版本信息? 背景 目前互联网上充斥着大量的关于RESTful API(为了方便,以后API和RESTful API 一个意思)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完

RESTful API 设计最佳实践

1. 背景 REST(英文:Representational State Transfer,表述性状态转移)描述了一个架构样式的网络系统,比如 web 应用程序. 目前互联网上充斥着大量的关于RESTful API(为方便,下文中"RESTful API "简写为"API")如何设计的文章,然而却没有一个"万能"的设计标准:如何鉴权?API 格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完的时候,你

RESTful API 设计最佳实践(转)

背景 目前互联网上充斥着大量的关于RESTful API(为方便,下文中“RESTful API ”简写为“API”)如何设计的文章,然而却没有一个”万能“的设计标准:如何鉴权?API 格式如何?你的API是否应该加入版本信息?当你开始写一个app的时候,特别是后端模型部分已经写完的时候,你不得不殚精竭虑的设计和实现自己app的public API部分.因为一旦发布,对外发布的API将会很难改变. 在给SupportedFu设计API的时候,我试图以实用的角度来解决上面提到的问题.我希望可以设计

基于Django RESTframework设计Restful API

导语 ? 关于RESTful的问题,在最近的面试中遇到很多,之前有过一定的了解,但没有系统性的总结分析.所以现在结合Django RESTframework来加深对RESTful的理解,同时梳理这过程的一些知识点. 什么是RESTful? ?这个问题是最容易想到的,首先要分析这个问题,网上的其他文章都会讲到有关REST(Representational State Transfer),中文翻译:"表述性状态传递",再白话一点就是对资源的表述性状态传递.刚开始,看到这里头都大了,那我们来

RESTful API的设计原则

最近一直在做公司的一个API平台的项目,前后大约有半年多了,中间穿插了好多其他的项目一起做的.上周经理要求写文档,我就重新打开项目开始检阅之前的代码,发现好多地方当初设计的并不合理,忽然就想到,一个好的API平台,应该怎么来设计呢?有哪些规范要遵守呢?面对自己的项目,感觉好多地方都要改,但是已经有人在用了,怎么办?全都要改动吗?所以就上网找解决方案,然后就发现一精品贴,现转载过来,以备不时查阅. 原文地址:http://www.cnblogs.com/moonz-wu/p/4211626.htm

好RESTful API的设计原则

说在前面,这篇文章是无意中发现的,因为感觉写的很好,所以翻译了一下.由于英文水平有限,难免有出错的地方,请看官理解一下.翻译和校正文章花了我大约2周的业余时间,如有人愿意转载请注明出处,谢谢^_^ Principles of good RESTful API Design 好RESTful API的设计原则 Good API design is hard! An API represents a contract between you and those who Consume your da

flask开发restful api

在此之前,向大家说明的是,我们整个框架用的是flask + sqlalchemy + redis.如果没有开发过web,还是先去学习一下,这边只是介绍如果从开发web转换到开发移动端.如果flask还不是很熟悉,我建议先到这个网站简单学习一下,非常非常简单.http://dormousehole.readthedocs.org/en/latest/ 一直想写一些特别的东西,能让大家学习讨论的东西.但目前网上的很多博客,老么就按照官方文档照本宣读,要么直接搬代码,什么都不说明.我写这个系列的博客,

拿nodejs快速搭建简单Oauth认证和restful API server攻略

拿nodejs快速搭建简单Oauth认证和restful API server攻略:http://blog.csdn.net/zhaoweitco/article/details/21708955 最近一直在鼓捣这个东西,拿出来分享下一下经验吧,其实很简单,一点也不难. 首先需求是这样,给自己的网站要增加API服务,API分为两种,公共的和私有授权的,授权的使用Oauth方法认证身份,API格式均为JOSN和JSONP. 嗯,别的语言我也没怎么学过,首先是找合适的框架进行实现吧.本身网站使用的e