标签：http 请求 students 接口 api CBV 服务端 FBV

1 FBV ：function based view 基于函数实现的视图逻辑

2 CBV：class based view 基于类实现的视图逻辑

1 前后端分离模式

在开发Web应用中，有两种应用模式：

1.前后端不分离[客户端看到的内容和所有界面效果都是由服务端提供出来的。]

2.前后端分离【把前端的界面效果(html，css，js分离到另一个服务端，python服务端只需要返回数据即可)】

前端形成一个独立的网站，服务端构成一个独立的网站

2 api接口

应用程序编程接口（Application Programming Interface，API接口），就是应用程序对外提供了一个操作数据的入口，这个入口可以是一个函数或类方法，也可以是一个url地址或者一个网络地址。当客户端调用这个入口，应用程序则会执行对应代码操作，给客户端完成相对应的功能。

当然，api接口在工作中是比较常见的开发内容，有时候，我们会调用其他人编写的api接口，有时候，我们也需要提供api接口给其他人操作。由此就会带来一个问题，api接口往往都是一个函数、类方法、或者url或其他网络地址，不断是哪一种，当api接口编写过程中，我们都要考虑一个问题就是这个接口应该怎么编写？接口怎么写的更加容易维护和清晰，这就需要大家在调用或者编写api接口的时候要有一个明确的编写规范！！！

为了在团队内部形成共识、防止个人习惯差异引起的混乱，我们都需要找到一种大家都觉得很好的接口实现规范，而且这种规范能够让后端写的接口，用途一目了然，减少客户端和服务端双方之间的合作成本。

目前市面上大部分公司开发人员使用的接口实现规范主要有：restful、RPC。

RPC（ Remote Procedure Call ）: 翻译成中文:远程过程调用[远程服务调用]. 从字面上理解就是访问/调用远程服务端提供的api接口。这种接口一般以服务或者过程式代码提供。

• 服务端提供一个唯一的访问入口地址：http://api.xxx.com/ 或 http://www.xx.com/api 或者基于其他协议的地址

• 客户端请求服务端的时候，所有的操作都理解为动作(action)，一般web开发时，对应的就是HTTP请求的post请求

• 通过请求体参数，指定要调用的接口名称和接口所需的参数

  action=get_all_student&class=301&sex=1

  m=get_all_student&sex=1&age=22

  command=100&sex=1&age=22

rpc接口多了,对应函数名和参数就多了,前端在请求api接口时难找.对于年代久远的rpc服务端的代码也容易出现重复的接口

restful: 翻译成中文: 资源状态转换.(表征性状态转移)

• 把服务端提供的所有的数据/文件都看成资源， 那么通过api接口请求数据的操作，本质上来说就是对资源的操作了.

  因此，restful中要求，我们把当前接口对外提供哪种资源进行操作，就把资源的名称写在url地址。

• web开发中操作资源，最常见的最通用的无非就是增删查改，所以restful要求在地址栏中声明要操作的资源是什么。然后通过http请求动词来说明对该资源进行哪一种操作.

  POST http://www.xxx.com/api/students/ 添加学生数据

  GET http://www.xxx.com/api/students/ 获取所有学生

  GET http://www.xxx.com/api/students/1/ 获取id=pk的学生

  DELETE http://www.xxx.com/api/students/1/ 删除id=pk的一个学生

  PUT http://www.xxx.com/api/students/1/ 修改一个学生的全部信息 [id,name,sex,age,]

  PATCH http://www.xxx.com/api/students/1/ 修改一个学生的部分信息[age]

也就是说，我们仅需要通过url地址上的资源名称结合HTTP请求动作，就可以说明当前api接口的功能是什么了。restful是以资源为主的api接口规范，体现在地址上就是资源就是以名词表达。rpc则以动作为主的api接口规范，体现在接口名称上往往附带操作数据的动作。

3 RESTful API规范

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中。

RESTful是一种专门为Web 开发而定义API接口的设计风格，尤其适用于前后端分离的应用模式中。

这种风格的理念认为后端开发任务就是提供数据的，对外提供的是数据资源的访问接口，所以在定义接口时，客户端访问的URL路径就表示这种要操作的数据资源。

而对于数据资源分别使用POST、DELETE、GET、UPDATE等请求动作来表达对数据的增删查改。

GET	/students	获取所有学生
请求方法	请求地址	后端操作
POST	/students	增加学生
GET	/students/	获取编号为pk的学生
PUT	/students/	修改编号为pk的学生
DELETE	/students/	删除编号为pk的学生

restful规范是一种通用的规范，不限制语言和开发框架的使用。事实上，我们可以使用任何一门语言，任何一个框架都可以实现符合restful规范的API接口。

参考文档：http://www.runoob.com/w3cnote/restful-architecture.html

接口实现过程中，会存在幂等性。所谓幂等性是指代客户端发起多次同样请求时，是否对于服务端里面的资源产生不同结果。如果多次请求，服务端结果还是一样，则属于幂等接口，如果多次请求，服务端产生结果是不一样的，则属于非幂等接口。

请求方式	是否幂等	是否安全
GET	幂等	安全
POST	不幂等	不安全
PUT/PATCH	幂等	不安全
DELETE	幂等	不安全

4 CBV使用

之前我们用的视图函数叫FBV（也就是函数型视图函数），这里我们来试试CBV（类视图函数）的写法。类视图函数可以让代码看起来更简洁，用起来更方便。

view.py

from django.shortcuts import HttpResponse
from django.views import View
from api.models import Book
from django.core import serializers

# FBV模式
def index(request):
    if request.method == "GET":
        return HttpResponse('get...')
    elif request.method == "POST":
        return HttpResponse('post...')
    elif request.method == "DELETE":
        return HttpResponse('delete...')


# CBV模式
class IndexView(View):

    # 如果是get请求那么会自动调用该方法
    def get(self, request):
        return HttpResponse('get cbv...')

    # 如果是post请求那么会自动调用该方法
    def post(self, request):
        return HttpResponse('post cbv...')

    # 如果是delete请求那么会自动调用该方法
    def delete(self, request):
        return HttpResponse('delete cbv...')

      
# 这就是数据接口
class BookView(View):
    def get(self, request):
        # 获取数据
        book_list = Book.objects.all()

        # 序列化：json
        data_json = serializers.serialize("json", book_list)

        return HttpResponse(data_json, content_type="json")
      # content_type 指定序列化类型，客户端能看的出

urlpatterns = [
    path('admin/', admin.site.urls),
    # FBV模式
    path('index/', views.index),
    # CBV模式
    path('IndexView/', views.IndexView.as_view()),
    # as_view()作用像是分发，什么请求方式就走什么方法。
  	path("books/",views.BookView.as_view())
]

标签：http,请求,students,接口,api,CBV,服务端,FBV
来源： https://www.cnblogs.com/it-lkp/p/16575274.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。