前端和后端交互的一些原规范问题

本文详细介绍了前后端开发中常见的交互问题,包括数据请求URL、接口文档编写、数据格式选择、请求参数形式等内容,并提供了实际工作中如何有效沟通及合理分工的建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近自己做后台,跟前端的一些有交集的问题总是工作内容划分不清楚,找了下网上搜了搜相关管理的资料

应,总结了下供大家参考,有好的意见求交流==

该怎么去规避一些不该属于自己的任务而被后台强加于自己?等等问题,
关于交互会给大家详细介绍9个方面的细节:

1.前端请求数据URL由谁来写?

在开发中,URL主要是由后台来写的,写好了给前端开发者.如果后台在查询数据,需要借助查询条件才能查询到前端需要的数据时,这时后台会要求前端提供相关的查询参数,这里的查询参数也就是URL请求的参数。

2.接口文档主要由谁来写?

接口文档也是主要由后台开发者来写的,因为直接跟数据打交道的就是后台,后台是最清楚,数据库里面有什么数据,能返回什么数据.前端开发只是数据的被动接受者.所以接口文档也主要是由后台来完成的,前端只是接口文档的使用者,使用过程中,发现返回的数据不对,则需要跟后台进行商量,由后台来修改.切记 前端不要随意更改接口文档,除非在取得后台开发人员的同意的情况下.总的来讲,接口文档主要由后台来设计,修改,前端开发者起到了辅助的作用.

3.前端开发与后台交互的数据格式主要是什么?

主要是JSON
XML现在用的不多

4.前端开发的后台交互原理?

在项目的时候,我们前后端会大概说一下接口地址,前端请求的参数,后端返回的参数,然后大家就开始写,写的差不多的时候,大家调一下接口看一下返回的数据,没问题就可以了。

5.前端请求参数的形式

GET和POST两种方式
对安全性不高 采用get方便
post要比get安全
GET - 从指定的服务器中获取数据
POST - 提交数据给指定的服务器处理

6.前端应该告知后台哪些有效信息,后台才能返回前端想的数据的呢?

先将要展示的页面内容进行模块划分,将模块的内容提取出来,以及方便前端的一些标志值等,将所有想要的内容和逻辑告知后端,
后端就会去数据库里面去查找相应的数据表中去获得相应的内容,或者图片地址信息。
URL中的参数主要是根据后台需要,
如果后台需要一个参数作为查询的辅助条件 前端在URL数据请求时就传递参数。
参数前面?
几个参数中间&

7.我们应该怎么把页面这些信息有效传达给后台,以及后台是如何获取到这些数据?

总的来讲:所有前端请求的URL后面的参数,都是辅助后台数据查询的.如果不需要参数,那么后台就会直接给个URL给前端.

8.前端应该如何回拒一些本不属于自己做的一些功能需求或任务?

在与后台打交道中,我们经常遇到这种情况,有时候明明后台来处理某个事件很简单,后台非要你来做,这时候我们应该懂得去回绝他.
原则:前端就是负责把数据展示在页面上
发挥:这就需要我们对一个需求,一个任务的要有清晰认识了,如果对任务含糊不清,自己都没搞明白,你只能受后台摆布了.最后也会因为任务没有完成而备受责难了.

9.当前端在调用数据接口时,发现有些数据不是我们想要的,那么前端应该怎么办呢或者怎么跟后台讲呢?

首先要把请求的URL和返回的数据以及在页面的展示的情况给跟后台看,这样有理有据,后台开发人员是不会说什么的,否则,后台会很不耐烦的,甚至骂你的可能都有,本身做后台比较难,尤其在查询数据,取数据,封装数据方面都比较难处理.

10.为什么需要在请求的时候传入参数?

因为后台在查询数据库的时候需要条件查询。

<think>嗯,用户这次明确提出了想了解前端后端交互的方式技术栈。从对话历史来看,用户之前可能已经对前后端分工有了基本概念(通过引用3),现在想深入具体的交互机制。用户可能是刚入门的开发者,或者正在做全栈学习的过渡阶段。用户给出的三条引用中,引用1提到了API接口学习路径,引用2讨论了前端技术栈选择,引用3对比了前后端职责——这些正好构成回答的基础框架:先明确交互需求(为什么交互),再介绍具体技术手段(怎么交互),最后落到技术选型(用什么交互)。需要注意用户特别提到“不是真正需求”的提示,说明用户更期待我结合通用知识而非局限于引用内容。因此我决定这样组织:1.先用分层框架解释交互的本质(请求-响应模式),呼应引用3的核心职责划分2.重点展开RESTfulAPI这个最通用的方式,因为引用1提到它是学习起点3.补充SSRWebSockets等特殊场景方案,覆盖完整技术谱系4.技术栈部分要区分前端请求工具(axios等)后端框架(Spring/Express等),因为引用2强调技术栈选择的重要性5.最后给实践建议时,特意加入调试工具Postman,解决新人最常见的接口调试痛点在格式上,用户似乎偏好清晰的模块划分(参考之前快速排序的示例),所以用标题分层且保持段落简短。技术术语首次出现时都简单说明,比如解释SSR时用括号注明“服务端渲染”。对了,用户要求行内公式也用LaTeX,不过这个纯技术话题涉及到的数学表达较少,只在解释GraphQL的查询语言时考虑要不要写语法示例。权衡后决定纯文字描述,避免过度复杂化。</think> 以下是前端后端交互的核心方式及技术栈详解,结合最佳实践行业标准: ### 一、交互核心方式 1. **HTTP(S) 协议请求** - **RESTful API**(主流方式) - 前端通过`GET/POST/PUT/DELETE`等方法请求后端接口 - 数据格式:`JSON`(占90%场景)或`XML` - 状态码规范:`200`(成功)、`401`(未授权)、`500`(服务错误)等 - **GraphQL**(新兴方案) - 前端可定制所需字段,减少冗余数据传输 - 例:查询用户姓名邮箱 ```graphql query { user(id: "1") { name email } } ``` 2. **实时交互技术** - **WebSocket**(双向通信) - 适用场景:聊天室、实时数据监控(股票行情) - 建立过程: ```mermaid sequenceDiagram 前端->>后端: HTTP Upgrade请求 后端-->>前端: 101 Switching Protocols 前端->>后端: WebSocket数据后端->>前端: 实时推送数据 ``` - **SSE**(Server-Sent Events) - 后端单向推送(如新闻播报) - 兼容性优于WebSocket 3. **传统服务端渲染**(SSR) - 后端生成完整HTML(如Java JSP/PHP) - 正在被Next.js/Nuxt.js等现代框架优化 ### 二、前端技术栈(请求发起端) | 工具类型 | 代表技术 | 特点 | |----------------|------------------------|-------------------------------| | 请求库 | Axios(主流)/Fetch API | 支持Promise、拦截器、超时控制 | | 状态管理 | React Query/SWR | 自动缓存API响应 | | 表单处理 | React Hook Form | 高效表单校验+提交集成 | | 类型安全 | TypeScript | 减少接口数据类型错误 | ### 三、后端技术栈(响应端) ```mermaid graph LR A[Web服务器] --> B[Nginx/Apache] C[应用框架] --> D[Node.js/Express/Koa] C --> E[Spring Boot(Java)] C --> F[Django/Flask(Python)] G[数据库] --> H[MySQL/PostgreSQL] G --> I[MongoDB/Redis] J[API网关] --> K[Kong/Apollo] ``` ### 四、减少依赖的最佳实践[^1] 1. **契约驱动开发** - 使用**OpenAPI/Swagger**定义接口规范 - 前后端可并行开发 2. **Mock服务** - 前端通过`Mock.js`模拟接口响应 3. **版本管理** - 接口路径包含版本号:`/api/v1/users` 4. **错误标准化** - 统一错误格式: ```json { "code": "AUTH_001", "message": "Token失效" } ``` ### 五、调试工具推荐 1. **Postman**:接口测试/文档生成 2. **Chrome DevTools**:网络请求分析 3. **Wireshark**:抓包分析(HTTPS需解密) > **关键趋势**:BFF(Backend For Frontend)模式兴起,通过中间层聚合多个后端接口,优化前端数据获取效率[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值