RESTful设计风格

简介: RESTful设计风格

对于http接口的调用,其历程经历过原始servlet,到后面的struts,SpringMVC,对于后端的参数封装也逐渐从单个属性演变成对象封装,然而即使到现在,我们对于http接口的封装,仍有不少公司采用下述示例:

@ApiOperation("执行")
@PostMapping("/execute")
public Result<Void> execute(@Valid @RequestBody ExecuteRequest request) {
    // 业务逻辑处理...
    return Result.success();
}

在这种模式下,开发人员一般将功能(或页面)聚合成一个controller,接口的路径定义也具备行为的特征,如对订单的操作,接口的定义一般形似(如删除、ID查询也可DELETE/GET):

功能

协议

接口

参数

新增

POST

/order/save

OrderSaveRequest

修改

POST

/order/update

OrderUpdateRequest

删除

POST

/order/delete

OrderDeleteRequest

ID查询

POST

/order/getById

OrderSingletonQueryRequest

复杂查询

POST

/order/get

OrderQueryRequest

在这种模式下我们对于订单协议的封装存在一个明显的问题:订单这个资源其行为是不规范的,同样是删除,有的人员定义为POST请求,有的是GET请求,资源表现的行为没有一个统一标准。更有甚者甚至会将order的功能封装成多个路径:save/order、save/product,这对于后续协议的维护简直就是灾难级别。因此我们需要一种设计规范,将程序员对于同一资源的行为封装做到规范统一。

总结为RESTful风格的设计拥有以下特点:结构清晰、统一标准、易于理解、扩展方便。

什么是RESTful

Resource Representational State Transfer:资源具象状态传输

RESTful是一个理念,是一个设计规范,而并非什么协议,其主要关键词如下:

资源

RESTful的理念下,互联网中任意信息都可定义为资源,如上述对于订单的增删改查,在此就抽象为订单资源;资源会对应一个特定的URI,URI为每一个资源的地址或独一无二的标识符,对应订单就可抽象为:http://application/order。此时订单抽象为资源,资源对应唯一的URI,后续对此资源的操作都将遵循此URI。

表现层

针对资源对外输出的展现,这种呈现形式称之为表现层。以为本为例可以对外呈现为:json/xml/html等多种格式。

状态转化

客户端通过访问服务端,进行增删改查操作,从而对资源状态产生变化,这个过程便是:资源的状态转化。以http协议为例(RESTful不仅使用HTTP协议,只不过是经常以HTTP协议为衬托),客户端可通过一些操作让服务端的资源进行变化。整个过程即为:表现层状态转化。而HTTP协议中常见操作方式:GET/POST/PUT/DELETE

如何使用RESTful

资源

GET

PUT

POST

DELETE

一组资源的URI,比如http://example.com/resources/

列出URI,以及该资源组中每个资源的详细信息(后者可选)

使用给定的一组资源替换当前整组资源

在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL

删除整组资源

单个资源的URI,比如http://example.com/resources/142

获取指定的资源的详细信息,格式可以自选一个合适的网络媒体类型(比如:XML、JSON等)

替换/创建指定的资源。并将其追加到相应的资源组中。

把指定的资源当做一个资源组,并在其下创建/追加一个新的元素,使其隶属于当前资源。

删除指定资源

RESTful使用进阶

上面对于RESTful的理解和使用我们有了一个认知,但是如果不能在涉及之初就对资源进行合理的划分,RESTful将变成只是针对现有功能的包路径调整。因此我们最好可以在设计之初就引入对应的资源概念。

1.架构中引入资源(Resource)的概念

最常见的错误就是在URI中包含动词,比如URI=http://example.com/getOrder?orderId=1234,其实「资源」表示一种实体,所以应该是名词,动词应该放在HTTP协议中。而与此同时URI也有可能破坏HTTP GET的安全性和幕等性,比如某个客户端在上执行GET(而不是POST),就能创建一笔新的咖啡订单(一个资源),按理来说GET请求不能改变服务的任何状态。

2.每一个URI代表一种资源,支持HTTP动词

此时使用多个URI的话,需要让不同的URI代表不同的资源(多个URI可能指向同一个Resource,而一个URI不能指向不同Resource),同时使用多个HTTP方法操作这些资源,例如使用POST/GET/PUT/DELET分别进行CRUD操作。这时候HTTP头和有效载荷都包含业务逻辑,例如HTTP方法对应CRUD操作,HTTP状态码对应操作结果的状态。我们现在看到的大多数所谓RESTful API做到的也就是这个级别。

目录
相关文章
|
Kubernetes Shell 容器
Kubernetes的kubectl命令补全
Kubernetes的kubectl命令补全
462 0
|
API Windows
怎么申请 bing api key
1:打开网址 https://login.live.com/ 注册帐号并登录(点击上图中的登录按钮即可),在新窗口点击下方的“立即注册”(有帐号的可以直接登录)2:填写相关信息(推荐使用hotmail邮箱),填写完毕后点击下方的 即可PS:国家或地区请勿选择‘中国’,否则会出现‘在你的市场中未提供...
20033 1
|
4月前
|
存储 自然语言处理 算法
RAG系统文本分块优化指南:9种实用策略让检索精度翻倍
本文深入探讨了RAG系统中的九种文本分块策略。固定大小分块简单高效,但可能破坏语义完整性;基于句子和语义的分块保留上下文,适合语义任务;递归与滑动窗口分块灵活控制大小;层次化和主题分块适用于结构化内容;特定模态分块处理多媒体文档;智能代理分块则通过大语言模型实现动态优化。开发者需根据文档类型、需求及资源选择合适策略,以提升RAG系统的性能和用户体验。作者Cornellius Yudha Wijaya详细分析了各策略的技术特点与应用场景。
684 1
RAG系统文本分块优化指南:9种实用策略让检索精度翻倍
|
9月前
|
机器人 应用服务中间件 API
轻松集成私有化部署Dify文本生成型应用
Dify 是一款开源的大语言模型应用开发平台,融合了后端即服务(Backend as Service)和 LLMOps 的理念,使开发者能快速搭建生产级生成式 AI 应用。通过阿里云计算巢,用户可以一键部署 Dify 社区版,享受独享的计算和网络资源,并无代码完成钉钉、企业微信等平台的应用集成。本文将详细介绍如何部署 Dify 并将其集成到钉钉群聊机器人和企业微信中,帮助您轻松实现 AI 应用的定义与数据运营,提升工作效率。
4671 65
轻松集成私有化部署Dify文本生成型应用
|
10月前
|
监控 数据可视化 关系型数据库
Dify: 一款宝藏大模型开发平台: 部署及基础使用
Dify 是一款开源的大语言模型(LLM)应用开发平台,融合了后端即服务(Backend as Service)和 LLMOps 的理念,使开发者可以快速搭建生产级的生成式 AI 应用。即使非技术人员也能参与 AI 应用的定义和数据运营。计算巢提供了 Dify 的快速部署解决方案,包括单机版和高可用版,支持通过 Docker Compose 和阿里云 ACK 部署,适用于开发测试和生产环境。用户可以通过配置 API、WebApp 脚手架等轻松集成 Dify 到业务中,极大简化了大语言模型应用的开发流程。
5824 22
Dify: 一款宝藏大模型开发平台:  部署及基础使用
|
人工智能 数据可视化 开发者
快速部署 Dify 社区版
Dify.AI 是一款 LLMOps 平台,帮助开发者更简单、更快速地构建 AI 应用。它的核心理念是通过可声明式的 YAML 文件定义 AI 应用的各个方面,包括 Prompt、上下文和插件等。Dify 提供了可视化的 Prompt 编排、运营、数据集管理等功能。这些功能使得开发者能够在数天内完成 AI 应用的开发,或将 LLM 快速集成到现有应用中,并进行持续运营和改进,创造一个真正有价值的 AI 应用。本文介绍使用计算巢快速部署 Dify 社区版。
快速部署 Dify 社区版
|
存储 JSON Shell
Jupyter Lab 的 10 个有用技巧
JupyterLab是 Jupyter Notebook「新」界面。它包含了jupyter notebook的所有功能,并升级增加了很多功能。它最大的更新是模块化的界面,可以在同一个窗口以标签的形式同时打开好几个文档,同时插件管理非常强大,使用起来要比jupyter notebook高大尚许多。
492 0
Jupyter Lab 的 10 个有用技巧
|
关系型数据库 MySQL 数据库
Docker安装部署PostgreSQL数据库
Docker安装部署PostgreSQL数据库
13651 0