粉丝2405获赞1.3万

来写这个 a p i 的这个方法, 我们数数 a p i 吧, 使用的时候需要返回这么几个参数,第一个就是返回来我们的这个提示信息,就 msd, 那我们就可以定义一个得了。 msd 等于先默认为空,然后还有里面有一个 数据,那我们同样到这一场等于空,数组还有个扣的,这个扣的的话我们默认为两百,他是状态码,状态码的话我们可以 呃,是两百呀,四零四呀这一类的,同样我们可以再设置一个错误码, 就是有可能我们报错了,我先试一下三个九吧,四个九,有可能,我们有可能我们报错了,我们需要去怎么去调整来,现在我我们来 reten 使用性 pp 里面封装好的这个 jason 的这个数组就可以,它这个里面前面是一个 数据,后面是一个状态,这个状态的话我们就可以把扣子传进去,这数据的话我们可以传上一个 result, 那这个 result 没有定义,我们需要去定义一下,到了 result 等于我们这个数组 出组的情况下,我们需要去怎么去操作呢?我们首先它里面有个其实信息,我们使用常过来的 mse, 同样数据我们推过来, 这样我们就会返回来一个 jason 的一个数据,那我们, 嗯,我们可以直接访问一下,访问一下这个 重启哈, jason 收 a p i, 看,这样就返回来我们需要的这个 jason 的这个格式,那同样我们返回到 我们这边的数据,我们可以 return 一下, return, 你前面的验证是要加啊,你们加完验证之后,错误码的话,你可以指定一个对应的错误码,然后呃错误信息你也可以自己去指定,也可以是后台,就是呃 validit 里面你可以自定义的这些错误信息, 我们直接就可以 dollar this, 我们这个方法里面呢收 api, 我们现在需要去传这个参数了, 这就是,嗯, a d d, 我们就说插入成功, 当然这个是要跟模型去关联的,关联之后模型那边返回来,如果成功的话,我们再去调用这个 ap 的这个接口,那数据的话我们就到了这个传过去, 然后 code 那肯定就是两百,错误码的话,我们就我们不填了, 默认,因为我们正常返回了吗?然后我们再去在这这个里面去调用的时候,看一下我们这边的代码, 我们打印一下,我们就知道我们返回来了没有, 我们先看一下控制台啊,刷新一下一二三,一二三,看到没有插入成功。迪塔,迪塔也有,迪塔里面数据是内蒙一二三,遇到内蒙 一二三,这,这就是我们需要拿到的这个结果,我们拿到这个结果就可以做相应的事情。像一般情况下我们可以来判断一下 a f, 判断 r e s, 点 c o d 等于两百,那就证明我们请求成功了。请求成功之后我们可以呃打印一下这个 提示信息,我们把下面这个删掉,让他老是碍事,我们刷新一下,刷新完成之后我们就可以看到我们登录上号密码, 我们拿到数据了,然后我们还可以对应的提示信息告诉我们这个动作完成之后,我们就可以做相应的这个跳转呀,或者是怎么回事,当然你从这个 那我们去请求这个 a、 d、 p 的接口,我们可以看一下删掉,那我现在给加上一个。

你是小阿八,刚入职的后端程序员,负责给前端的阿花提供 api 接口。结果一周后,你被阿花揍得鼻青脸肿。你是我这辈子见过接口写的最烂的程序员。你一脸委屈,找到号称开发之狗的鱼皮诉苦,哎,接口不是能跑就行吗? 鱼皮嘲笑道,小阿爸,你必须得学学 rest for api 了。阿爸阿爸,什么玩意儿?没听说过。首先, rest 的 全称是 representational state transfer, 翻译过来叫表现层状态转移。 你一脸懵,鱼皮爹爹能说人话吗?我是傻子,听不太懂。别急,我给你拆开来讲,保证你理解。先看 r e。 表现层是指资源的表现形式。 呃,什么是资源?资源就是你想要操作的数据对象,比如用户、商品、文章,这些都是资源。用户列表是一个资源,某个具体的用户也是一个资源。 表现层是指资源呈现出来的具体格式。比如同一个用户,资源可以用 jason 格式返回给客户端,也可以用叉 ml 格式返回,这就是不同的表现形式。 s 是 指状态。 啥是状态?比如你登录网站后,服务器会在内存中记住你是谁,之后在网站上操作,就不用再次登录了,这就是有状态。而无状态呢,就是服务器不记录客户端的任何信息,每次请求都是独立的。 哦哦哦,就像一个人去餐厅吃饭,服务员不记得他上次点了什么,每次都要重新点单,这就是无状态。反过来,服务员记得他爱吃鱼皮,这就是有状态。 没错,接下来是 t 转移。要注意,转移是双向的,当你用 get 请求时,服务器把资源的状态转移给客户端,当你用 post 请求时,客户端把资源的新状态转移给服务器,从而改变服务器上资源的状态 组合起来。 rest 是 一种软件架构风格,让客户端和服务器通过统一的接口,以无状态的方式互相传递资源的表现层数据来查询或者变更资源状态。而 for 是 个后缀,就像 power 充满力量的一样,表示充满某个特性的。 因此, restful api 是 指符合 rest 架构风格的 api。 注意,它不是协议,不是标准,不是强制规范,只是一种建议的设计风格,你可以遵循,也可以不遵循。你挠了挠头,说了一大堆, restful api 到底长啥样啊? 举个例子,比如你要做着用户管理系统对用户信息进行增删改查,用 restful 风格的 api 就 长这样。 哇,比我写的整齐多了,快带我学一下 restful 的 写法吧,我要让前端阿花刮目相觑。好很有志气,接下来我会带你一步步构造一个完整的 restful api, 分 为两部分,客户端发送请求和服务端给出响应。 先来构造客户端请求,第一步是确定资源,资源用 u r i 统一资源标识符来表示,核心原则是用名词来表示资源,而不用动词。具体来说,推荐用名词复数表示资源集合。比如 users 表示用户列表, products 表示商品列表。 如果要操作具体某一个资源,就加上 id, 比如 us 杠一二三,表示 id 为一二三的用户资源,还支持嵌套,比如 us 杠一二三杠 alt 表示用户一二三的所有订单。 呃,那还可以正深层级吗?比如表示用户一二三的订单,四五六。鱼皮点点头,你的理解完全正确,但不建议嵌套层级太深。 确定了资源后,接下来要选择动作,也就是你想怎么处理这的资源。 restful api 主要通过不同的 http 方法来表示,增删改查操作、 get 查询资源、 host 创建资源、 put 完整更新资源、 patch 部分更新资源和 delete 删除资源。到这里,一个基本的 restful api 请求就构造完成了。呃,就这么简单,我不满足,还有正着急的写法吗? 当然有,有时我们需要更精确的筛选数据,这时候就可以加查询参数,比如分页、过滤和排序 等等。这查询参数跟 restful 有 啥关系?正常的请求不都是这么写吗?确实,查询参数本身不是 restful 特有的,但 restful 风格强调把筛选、排序、分页这些操作都通过 url 参数来表达,而不是在请求体里传一堆复杂的 json 对 象。 这样一来, u r l 更清晰。而且浏览器 c、 d、 n 代理服务器都能直接根据 u r l 来缓存响应结果,不同的 u r l 可以 分别缓存,更容易区分。 随着业务发展,接口还可能需要升级。为了不影响,老用户可以在 u r i 中标明版本,这样老用户继续用 v 一, 新用户用 v 二,互不影响。 此外,你还记得我们前面讲 rest 里的 s t 状态转移吗? rest for 的 核心原则之一是无状态客户端,每次请求必须包含所有必要信息,服务器不记录客户端的状态。比如用户登录后,不是让服务器记住你已经登录了,而是每次请求都要带上身份凭证,就像这样, 这么做的好处是,服务器不用记录,谁登录了谁没登录,每个请求都是独立的,这样一来,你想加多少台服务器都行,任何一台都能处理请求,轻松实现覆盖、均衡和横向扩展。你点头如捣蒜,怪不得我调用 ai 大 模型 api 的 时候就要传这这 toc。 讲完了客户端请求,再来看看服务器收到请求后该怎么响应。主要注意两点,首先是统一响应格式,目前大多数 restful api 基本都使用 jason 格式,因为清量容易解析,但这并不是强制的,也可以用叉、 ml、 html 等格式。 而且响应要带上合适的状态码,让客户端一眼看懂发生了什么。 http 状态码有很多,大致可以分为五类,重点关注。二叉叉表示成功,三叉叉表示重定向,四叉叉表示客户端错误,五叉叉表示服务器错误。 哦,俺懂了,以后前端看到五零零就知道是我,后端的锅看到四零零就知道是它。自己参数传错了,谁也别想甩锅。嗯,不错。以上这些就是 restful api 的 基本写法,你学废了吗? 学废了学废了。那我来考考你下面哪个是标准的 restful api? 你 开心的怪叫起来,阿爸,肯定是 c 啊, 错, no, 四个全都不标准。 a 用了动词, b 用了单数和动词, c 用 post 查询还带了动词, d 用 get 删除还带了动词。你掉了根头发 啊,原来这么严格。等等,你说 restful 不 能用动词,但有些操作不是标准的增删窄查,比如用户要支付订单,该怎么设计接口呢?是要这样写吗? 鱼皮摇摇头,你已经很努力了,但呸,是动词!更标准的设计是把支付行为看作创建一个支付记录用名词,而不是动词。 比如这个请求表示为订单幺二三创建一笔支付记录。你又掉了根头发,妙啊,怪不得说英语对学编程有帮助呢。我悟了,不错,学到这里,你已经掌握了 restful 的 百分之八十能够实际应用了。 接下来的知识,你只需简单了解一下,就能拿去和面试官吹牛皮了。比如很多同学都不知道, restful 其实有六个约束条件,包括客户端、服务器分离、无状态、可缓存、 分层系统、统一接口,还有按需代码。你直接听蒙了,阿爸阿爸,这么多约束,我必须全遵守吗? 可以不用, restful 只是一种 api 的 建议风格,在实际工作中,很少有 api 能完美符合所有约束,大家可以灵活调整,甚至什么接口都用 post 加动词一把缩, 只要团队达成一致,用的舒服就行。就像刚才那个支付订单的例子,虽然用名词符合 restful 规范,但有同学会觉得用动词更直观易懂也没问题。不过现阶段,我建议你先养成遵循 restful 的 好习惯,写出更漂亮的接口 喔。但我只是个小阿巴,背不下来这些写法,我怕自己写着写着就不规范了,怎么办啊? 别担心,有很多方法可以帮你快速实现和检查 restful api。 一、 使用开发窗架几乎所有主流开发窗架都支持 restful api 的 开发,它们能帮你自动处理很多细节,比如 java 的 spring boot, python 的 java 的 ginn, 这些框架虽然不强制你遵循 restful, 但用它们的特性开发起来既轻松又规范,帮你省掉大量重复代码。二、使用 ide 插件,比如 ide 二的 restful toolkit 插件,可以快速查看和测试接口。还有 vs code 的 rest client 插件,可以直接在编辑器里测试接口。 三、利用 ai 生成 restful, 有 明确的设计规范,而 ai 最擅长处理这种有章可循的东西。比如直接让 curser 帮你用 spring boot 写一个用户管理的 restful api, 你 只需要啊吧啊吧几下,它就能生成规范的代码。 写完接口后,还可以用 swagger 这类工具自动生成漂亮的接口文档,直接甩给前端,对方一看就懂,还能在线测试接口,省去大量沟通成本。你笑得像个孩子。 这么一看, restful api 不 仅上接口规范统一,还能提高开发效率,降低团队沟通成本,前后端都舒服爽爽爽! 没错,这也是为什么 restful 能成为业界主流的原因。学会了,学会了,我这就去重构所有接口,让前端阿花刮目相看。一周后,你把所有接口重构成了 restful 风格。前端阿花打开新的接口文档,眼睛亮了, 小阿巴,你居然开窍了!你得意地笑了,那是,我可是学过 restful 的 男人!阿花,晚上要不要一起?阿花朝你吐了口唾沫, 呸,你只不过学了一种 api 风格就得意洋洋,我阿坤哥哥不仅精通 restful, 还能手撕 graph q r 和 g r p c 呢,你行吗?呃?啥啥啥?这都是啥?玉皮弟弟快来救我!

前端如何编程实现向后端交互呢? vivo 语言是可以这么实现,分两个文件,一个是 vivo 后缀文件,负责页面展示及新增修改删除等交互操作。另一个是 js 后缀文件,负责定义交互接口, 其包括 er, messi 的及 parents 等参数 l 即 messi 的须根 java 的 controller 定义一致,这样就实现了前端吊用后端接口了。

新的一年里,祝大家一路长虹。在和前端对接接口的时候,如果我们能提供这样一份接口文档,那么前端对接起来也比较方便,也省了一些沟通上的成本。 下面来看一下这个是怎么样实现的,这里我们需要借助一下这个框架,它是对 swag 接口文档 ui 页面的一个增强。我这里使用的是一个微服务项目,那么我只要把这个依赖放到我的副工程的 pop 文件里面就可以。接下来就是在每一个微服务里面添加这样的配置。 我这里每一个服务的话都分成两类接口,一类是提供给后台管理用的,一类是提供给前端 app 使用的,所以的话就建了两个组。这个是接口文档的一个地址,接下来就是网关的一个配置,这个是它的依赖。 接着是在网关的配置文件里面添加这些配置,这里需要把网关这个服务给排除掉,网关的话它只负责一个接口的转发,并没有实际的业务。 然后的话就是把我们每一个服务的接口给配置到这里面,最后需要把每一个服务的这个接口文档的地址给放行,就不需要进行健全。最后给大家推荐几份实战手册, 这几份手册和这个项目是相辅相成的关系,手册里面包含了实战实力,而项目里面告诉你这些实战实力是怎么去应用的。 然后再给大家推荐一份关于 micro 理论知识讲的比较好的书籍,作者的话非常用心,把一些灰色难懂的知识都讲的比较清晰易懂。手册和书籍我都放到自己的橱窗了,项目的话过一段时间也会在橱窗上线。

用户通知,然后向那个前端你的这个页面是通过接口进行交互,然后我们发一个, 看他能不能生成。这里发送了一个请求,发了一个请求,然后他根据你发的这个饮食计划,然后你跟他回复了这个里面的要简备, 然后他这个模型再去请求后端接口。然后我们现在先看一下这个前端页面, 前端是这个 web ui 下面,然后那个对应的页面的话,就是 这个就是那个前端页面。然后我们找一下那个发送的按钮,这个就是发送按钮这儿,因为它这里是一个图标,所以说它没有字。然后我们找到这个发送图标以后, 嗯,就这里我跟你讲的东西是教你怎么看那个静态页面上发送按钮,然后在代码里面怎么进行交互的, 你看的啊,这里好好听着,然后搜一下这个 set message, 然后下面这个就是他具体的一些方法,然后我们看看他这个怎么写,这里是做了一些参数校验,然后接着往下我们找找他在哪调的接口, 这没问题,这没问题,这就开始发送消息, 然后到了这,然后他继续去查,反正这块逻辑挺复杂,需要你一层一层的去往下点,然后找到这,找到这以后呢,这是第五百三十行,在这,然后的话,到了这一步的话,你就可以去看到他在这去请求那个 对话接口,就 api hells 键,就请求那个问答接口,然后它这里它有有一个那个流逝,流流流逝响应这块就是它的那个最终的一个响应体。然后我们看一下这个对应的后端接口, 它在这里发了请求,到后端应该是在这有个对话,你看 pos 的 请求,然后对应的一些参数信息, 然后他在这接收到,然后他在这,在后段又实现了一个流式回答,反正这块注示也都有,你就照着这个注示去念就行了。知道他是个流式回答,然后他问题具体怎么实现的话, 嗯,你就跟他说通过他这个模型的一些啊, 通过他的这个,反正这个就是他具体一个实践方法,我也忘记用哪个技术去实践了,我给你找一下吧。嗯,在这儿 他通过这个 server, 这个应该就是他那个流水回滑流水回答的创建,反正就通过这个返回,就是这样的一个东西,他去返回的,然后给你看一下这个对应的页面样式, 然后你看他这个响应,他是怎么一个,他是一个字一个字的往回奔,他不是说一次性返回来的, 然后前端再接受他的这个接收到他这个字以后呢?前端再去给他做一个拼接,他这个就实现了一个流失回弹,他就一个字一个字往出奔,然后别的要讲的话也没啥了, 啊啊啊啊啊。

大家好,今天给大家带来一个答辩教程, deepsea 接口的调用,一个代码精讲啊啊,我们先来看一下,非常简单啊,非常简单, 首先呢我们代码里边呢,是放在哪个地方?是放在这里,大家注意看这个层级,这是代码,然后到它到它,到它到它,放在这里边, 这里边呢有一个他看到了吗?啊,有一个他这个接口啊,这一块就是关于你这个 deepsea 调用的一个这个啊代码,然后呢代码部分呢,我们给大家把它整理出来了,做了一个精讲啊,每一步注视了都很详细简单。再带大家看一下, 第一部分呢,非常简单,这个地方呢就是代码的请求地址啊,请求这个地址,调用后端接口。好,下面呢第一个叫定义请求同,然后设置请求的数据格式为摘散格式, 然后呢设置授权码,这是一个授权码啊,这个授权码当然你可以换成自己的 a k, 不 换无所谓啊。然后定义请求参数, 请求参数是一个摘餐对象,然后请求类型为这个 deep seek 的 聊天模式,然后请求的内容就是你,比如你输入你好啊,比如顺应问十万个为什么呀,这就是你输入的那个内容,好吧啊,内容好, 封装请求的对象,封江请求对象,这是一个请求对象,把这个刚才你这个请求的头啊,包括你请求的这个参数啊,给它放进去了, 然后请求 dbc 的 一个地址,我们是请求的这个地址,大家一看这个地址啊, a p r 什么什么很明确能够知道它是个干嘛的啊,好,调用它,获取返回结果,用它,然后调用它,大家看到了吧?哎?这一个是哪里定义的呢?这一个是, 这一个是哪里定义的?这个是哪里定义的?这个这里没写,我们返回到代码里边给大家看一下,这一个是在上面我们做了一个定义,在哪做那个定义, 大家看一看,这里做的一个定义,看到了吗?给大家展开一下啊,大家展开一下, 看到了吗?这里是他啊,这里是他 build, 看看这个 build, 这个 build 看到了吗?然后这里是他这个瑞斯,什么什么 build 作为参数进来,他直接调用这个 build, 可 build 是 啥呢?这个 build 我 们就不看了,为什么不看了呢?大家注意看,它是一个公用的这个这一个公用的客户端调用的一个对象啊,一个对象,你只需要知道这里是之前定义好的就可以, 这个不需要深究它啊,然后调用它,然后就是一个 url, url 这个地址下我用的 pos 的 请求啊,然后呢?结果它用的 host 请求,求的是这个对象啊,然后呢?获取这个返回的请求体 body 嘛?获取对象 body, 返回请求体,好 解析结果,这就是一个宅餐对象的一个解析了,非常简单,获取里边你要的这个 message 里边 content 的 获取返回的内容吗?对吧?然后将结果返回给前端,这就是一个简单的这个他的一个调用代码。