RESTful设计要素

资源路径

在RESTful架构中,每个网址代表一种资源,所以网址中不能有动词,只能有名词。一般来说API中的名词应该使用复数。

HTTP动词

对于资源的操作(CURD),由HTTP动词表示。

》GET:从服务器取出资源

》POST: 在服务器新建一个资源

》PUT : 在服务器更新资源(客户端提供改变后的完整资源)

》PATCH:在服务器更新资源(客户端提供改变的属性)

》DELETE: 在服务器删除资源

过滤信息

如果记录数量很多,服务器不可能都将他们返回给用户。API应该提供参数,过滤返回结果。

eg:

?offset=10: 指定返回记录的开始位置

状态码

使用标准的HTTP状态码

》200 OK 服务器成功返回用户请求的数据,该操作是幂等的

》201 CREATED 新建或修改数据成功

》204 NO CONTENT 删除数据成功

》400 BAD REQUEST 用户发出的请求有错误

》401 Unauthorized表示用户没有认证,无法进行当前操作

》403 Forbidden 表示用户访问是被禁止的

》422 Unprocesable Entity 当创建一个对象时,发生一个验证错误

》500 INTERNAL SERVER ERROR服务器发生错误,用户将无法判断发出的请求是否成功。

错误处理

如果状态码是4XX或者5XX,就应该向用户返回出错信息,一般来说,返回的信息中将error作为键名,出错信息作为键值即可:

{

  “error”: "参数错误"

}

返回结果

针对不同操作,服务器向用户返回的结果应该符合一下规范:

》GET/collections:返回资源对象的列表(数组)

》GET/collections/identity:返回单个资源对象,如果该资源不存在,则返回404状态码

》POST/collections:返回新生成的资源对象

》PUT/collections/identity:返回完整的资源对象

》PATCH/collections/identity: 返回被修改的属性

》DELETE/collections/identity:返回204状态码 和 一个空的响应体

原文地址:https://www.cnblogs.com/xiaoQ0725/p/8110513.html

时间: 2024-07-31 17:59:44

RESTful设计要素的相关文章

软件设计要素初探:架构模式

在 "软件设计要素初探" 一文,尝试从软件设计的整体角度,综合讨论了软件设计的各种要素.本文探讨系统组件交互的架构模式. 架构模式是系统组件及组件交互的模式,决定了处理数据和领域对象的全局控制结构.组件化是使用架构模式的前提. 可参阅 <面向模式的软件架构>了解更多架构模式. 分层模式 分层模式: 将应用划分为多个层次,定义各层的接口.任务抽象及消息格式,以及各层之间的通信与交互.业务系统通常会划分为业务逻辑层.服务层.领域层.数据层.网络栈协议是分层模式的典型应用.应用分

.NET应用架构设计—重新认识分层架构(现代企业级应用分层架构核心设计要素)

阅读目录: 1.背景介绍 2.简要回顾下传统三层架构 3.企业级应用分层架构(现代分层架构的基本演变过程) 3.1.服务层中应用契约式设计来解决动态条件不匹配错误(通过契约式设计模式来将问题在线下暴露出来) 3.2.应用层中的应用控制器模式(通过控制器模式对象化应用层的职责) 3.3.业务层中的命令模式(事务脚本模式的设计模式运用,很好的隔离静态数据) 4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型 5.两种独立业务层职责设计方法(可以根据具体业务要求来搭

软件设计要素初探:软件设计的一些子主题

在 "软件设计要素初探" 一文,尝试从软件设计的整体角度,综合讨论了软件设计的各种要素.本文主要探讨一些稍小的设计子主题,主要包括:错误处理.结构性难题.整体与兼容.设计取舍.设计与重构.设计与质量.设计与细节.维护与扩展.测量技术. 错误处理 错误处理关乎系统的健壮性,且是全局性设计问题.一个整体的错误处理架构主要包括两部分: 参数的严格校验.规范而易于理解的错误码和错误消息.无遗漏的异常捕获和转译.警告和错误日志输出: 一致的错误处理机制.不同级别错误的处理策略. 第一部分并不需要

软件设计要素初探:业务模式

在 "软件设计要素初探" 一文,尝试从软件设计的整体角度,综合讨论了软件设计的各种要素.本文讨论业务应用中的常见套路:业务模式. 概述 软件开发过程中,交织着对业务规则.业务流程的认识.理解.设计.实现.业务模式是对业务规则和流程的常见相似性.以及特定业务的数据处理能力的提炼,是业务应用系统中的常见套路.掌握这些套路,有助于更快更好地设计与实现业务. 模式清单 参数检测模式:调用身份检测.权限校验.空检测.时间参数检测.业务约束检测.存量检测: 健壮服务调用模式: 健壮地调用服务接口.

RESTful 设计理论

RESTful 设计: 1.协议通信协议:https 2.域名部署在API专用域名下,除非API很简单(https://www.example.com/api)https://api.example.com 3.版本应将版本号放在url中(.../v1/...);也可以放在http头中 4.路径不能有动词,只能有名词:所用名词常和数据库表格名对应(ps:https://api.example.com/v1/users) 5.HTTP动词GET(SELECT):获取一个或多个 eg: /users

网站页面设计要素四大注意事项

第一.要具有特色 不管是新闻网站还是商业网站,具有一定的特色可以把网站的宗旨和理念有力地予以诠释,力求简单易记.形象生动.冲击力强.彰显力量.例如,一个设计精巧的LOGO,就能给用户带来惊喜,能够迅速地吸引用户的眼球,能在用户的心中留下深深的印记,最终提升网站影响力. 第二.整体设计简洁 文章发布的网站主要形成和性竞争力的功能就是提供海量切高价值的文章信息.用户访问的首要目的就是为了满足文章信息需求,目标明确切行为直接,就要做到表现形式与文章内容的和谐统一.在设计首页的时候,要力求整体简洁.朴素

RESTful设计原则和样例(开发前后台接口)

参考博文: http://www.cnblogs.com/artech/p/restful-web-api-02.html 维基百科:https://zh.wikipedia.org/wiki/REST 目前在三种主流的Web服务实现方案中,因为REST模式与复杂的SOAP和XML-RPC相比更加简洁,越来越多的web服务开始采用REST风格设计和实现.例如,Amazon.com提供接近REST风格的Web服务进行图书查找:雅虎提供的Web服务也是REST风格的. 要点及标准 需要注意的是,RE

WebApp 设计要素

从去年开始就负责公司WebApp的产品跟设计工作,最近整体大改了两个版本,也算累积了一些实际的经验.在不断学习的过程中,发现对于WebApp可以直接用于项目上的资料比较零碎,在这里总结一下,供初做 WebApp的设计师在实际项目中参考. 设计尺寸:基于宽度320px 一般大家看到的移动端设计尺寸参考都是基于ios或者Android,是绝对不能直接用于WebApp的设计中.而且常用的PS Play也不适用查看WebApp的效果. WebApp本质上还是一个网页,它的尺寸(特别是宽度)是依赖于每个手

RESTful API 设计

网络应用程序,分为前端和后端两个部分.当前的发展趋势,就是前端设备层出不穷(手机.平板.桌面电脑.其他专用设备......). 因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信.这导致API构架的流行. RESTful API 设计要素详见此文 :RESTful API 设计指南 以下简诉API的测试和它在PHP中的异常处理: 安装浏览器扩展工具 Restlet Client - DHC ,用于API的调试/测试 异常处理: /** * 常用状态码 * @var [type] */