发现一篇总结的比较全的文章 记录下来
转载自
szMacbook
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.为什么需要在请求的时候传入参数?
因为后台在查询数据库的时候需要条件查询。
关于接口
- 对于GET请求,数据在URL后通过标准的query格式提供,如GET /users?status=1,2&keyword=hello。
- 对于各系统,可以在URL前统一添加固定的前缀,如GET /api/{entities}/{id},前缀应尽量固定。可以根据请求的类型(如是否需要用户登录授权等)使用不同的前缀。规范推荐按以下规则使用前缀:
- 如果是需要登录授权的接口,以/api/js为前缀。
- 其它接口,通常没有权限控制,以/api/tool为前缀。
- 关于数据类型
- 请求可以使用以下两类数据类型,由具体的项目及接口根据实际情况决定:
- 表单编码格式。此格式为简单的a=b&c=d这一形式,使用此请求格式时,请求的Content-Type头的值必须为application/x-www-form-urlencoded。
- JSON格式。此格式为一个完整的符合JSON格式的串,使用此请求格式时,请求的Content-Type头的值必须为application/json。
- 响应可以使用以下几类数据类型:
- JSON格式。多数接口应当使用JSON格式的响应,此时响应的Content-Type头的值必须为application/json。
- HTML格式。部分接口,如文件上传,由于技术的限制必须使用<iframe>元素完成,返回的响应为一个HTML片段,此时响应的Content-Type头的值必须为text/html,且响应状态码必须为200,具体可参考下文的文件上传相关接口规范。
- JSONP格式。当跨系统调用API时,会需要使用JSONP接口,此时响应的Content-Type头的值必须为application/x-javascript,使用请求的URL中的callback字段的值为函数名返回相应的JSONP片段。
- 关于接口文档
- 接口文档应当 至少 包含以下内容:
- 接口的名称及简单的作用描述。
- 接口的URL和请求时使用的HTTP Method。
- 接口的请求格式及参数。
- 接口可能返回的状态码,及每个状态码下的响应类型和格式。
- 接口的缓存设计。
- 以下为一个典型的接口文档:
- ## 用户列表
- 用于获取用户列表,带分页功能
- ## 接口:
- GET /users
- ## 请求参数:
- | 名称 | 类型 | 定义 | 必需 | 默认值 | 说明
- | keyword | string | 查询关键词 | | "" | 作用于name和id字段
- | page | number | 页码 | | 1 |
- | role | number | 角色 | | 全部 | 参考角色枚举说明
- | orderBy | string | 排序字段名称 | | "id" | 可以使用"id"或"name"
- | order | string | 排序方式 | | "asc" | 可以为"asc"或"desc"
- ## 响应:
- ### 成功:200
- 响应格式:JSON
- {
- totalCount: {number}, // 总数
- results: [
- {
- "id": {number},
- "name": {string},
- "role": [{number}, ...], // 角色,多个角色用数组表示
- "birthday": {string}, // 生日使用YYYYMMDD格式
- },
- ...
- ]
- }
- 缓存配置:使用`ETag`进行缓存。
- ### 参数不合法:409
- 参考标准409响应
- 在文档中,对于一些整个项目统一的内容,如页码默认值为1之类,可以省略说明,在单独的总体设计文档中标注即可。
虽然很多时候一个api接口的业务,数据逻辑是后端提供的,但真正使用这个接口的是客户端,一个前端功能的实现流程与逻辑,有时候只有客户端的RD才清楚,从某种意义来说,客户端算是接口的需求方。
所以建议在前期接口设计和评审时,客户端的RD应该更多的思考和参与,什么时机调什么接口?每个接口需要哪些字段?数据含义怎么给?只有这些都考虑清楚,且达成一致并产出接口文档后,当项目真正启动时,根据接口协议进行开发,才能尽量避免各种不确定因素对项目整体进度的影响。