前后端交互原理 深入理解

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.为什么需要在请求的时候传入参数？

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

关于接口

1. 对于GET请求，数据在URL后通过标准的query格式提供，如GET /users?status=1,2&keyword=hello。  
2.     对于各系统，可以在URL前统一添加固定的前缀，如GET /api/{entities}/{id}，前缀应尽量固定。可以根据请求的类型（如是否需要用户登录授权等）使用不同的前缀。规范推荐按以下规则使用前缀：  
3.         如果是需要登录授权的接口，以/api/js为前缀。  
4.         其它接口，通常没有权限控制，以/api/tool为前缀。 
   

1. 关于数据类型  
2.   
3. 请求可以使用以下两类数据类型，由具体的项目及接口根据实际情况决定：  
4.   
5.     表单编码格式。此格式为简单的a=b&c=d这一形式，使用此请求格式时，请求的Content-Type头的值必须为application/x-www-form-urlencoded。  
6.     JSON格式。此格式为一个完整的符合JSON格式的串，使用此请求格式时，请求的Content-Type头的值必须为application/json。  
7.   
8. 响应可以使用以下几类数据类型：  
9.   
10.     JSON格式。多数接口应当使用JSON格式的响应，此时响应的Content-Type头的值必须为application/json。  
11.     HTML格式。部分接口，如文件上传，由于技术的限制必须使用<iframe>元素完成，返回的响应为一个HTML片段，此时响应的Content-Type头的值必须为text/html，且响应状态码必须为200，具体可参考下文的文件上传相关接口规范。  
12.     JSONP格式。当跨系统调用API时，会需要使用JSONP接口，此时响应的Content-Type头的值必须为application/x-javascript，使用请求的URL中的callback字段的值为函数名返回相应的JSONP片段。 
    

1. 关于接口文档  
2.   
3. 接口文档应当 至少 包含以下内容：  
4.   
5.     接口的名称及简单的作用描述。  
6.     接口的URL和请求时使用的HTTP Method。  
7.     接口的请求格式及参数。  
8.     接口可能返回的状态码，及每个状态码下的响应类型和格式。  
9.     接口的缓存设计。  
10.   
11. 以下为一个典型的接口文档：  
12.   
13. ## 用户列表  
14.   
15. 用于获取用户列表，带分页功能  
16.   
17. ## 接口：  
18.   
19. GET /users  
20.   
21. ## 请求参数：  
22.   
23. | 名称     | 类型   | 定义        | 必需 | 默认值 | 说明  
24. | keyword | string | 查询关键词   |     | ""    | 作用于name和id字段  
25. | page    | number | 页码        |     | 1     |  
26. | role    | number | 角色        |     | 全部   | 参考角色枚举说明  
27. | orderBy | string | 排序字段名称 |     | "id"   | 可以使用"id"或"name"  
28. | order   | string | 排序方式     |    | "asc"  | 可以为"asc"或"desc"  
29.   
30. ## 响应：  
31.   
32. ### 成功：200  
33.   
34. 响应格式：JSON  
35.   
36.     {  
37.         totalCount: {number}, // 总数  
38.         results: [  
39.             {  
40.                 "id": {number},  
41.                 "name": {string},  
42.                 "role": [{number}, ...], // 角色，多个角色用数组表示  
43.                 "birthday": {string}, // 生日使用YYYYMMDD格式  
44.             },  
45.             ...  
46.         ]  
47.     }  
48.   
49. 缓存配置：使用`ETag`进行缓存。  
50.   
51. ### 参数不合法：409  
52.   
53. 参考标准409响应  
54.   
55. 在文档中，对于一些整个项目统一的内容，如页码默认值为1之类，可以省略说明，在单独的总体设计文档中标注即可。 
    

关于接口设计

虽然很多时候一个api接口的业务，数据逻辑是后端提供的，但真正使用这个接口的是客户端，一个前端功能的实现流程与逻辑，有时候只有客户端的RD才清楚，从某种意义来说，客户端算是接口的需求方。

所以建议在前期接口设计和评审时，客户端的RD应该更多的思考和参与，什么时机调什么接口？每个接口需要哪些字段？数据含义怎么给？只有这些都考虑清楚，且达成一致并产出接口文档后，当项目真正启动时，根据接口协议进行开发，才能尽量避免各种不确定因素对项目整体进度的影响。