一 web开发模式 1. 前后端混合开发模式 前后端混合开发模式是一种开发方式,将前端和后端的开发工作结合在一起,以加快项目的开发速度和提高协作效率。这种模式通常用于快速原型开发、小型项目或敏捷开发中。在前后端混合开发模式中,前端和后端开发
前后端混合开发模式是一种开发方式,将前端和后端的开发工作结合在一起,以加快项目的开发速度和提高协作效率。这种模式通常用于快速原型开发、小型项目或敏捷开发中。在前后端混合开发模式中,前端和后端开发人员紧密合作,共同制定项目需求、设计界面和编写代码。具体来说,这种模式有以下特点:1.交叉开发:前端和后端开发人员在同一时间内并行进行开发,而不是先完成一个部分再进行另一个部分的开发。2.紧密协作:前端和后端开发人员之间需要密切合作,共同解决问题,制定接口规范,并确保前后端之间的数据交互和功能协调一致。3.接口规范:在前后端混合开发中,明确的接口规范尤为重要。前端和后端需要约定好数据传输的格式、接口命名和参数等。4.快速迭代:由于前后端同时进行开发,可以更快地进行迭代和调整,及时响应变化的需求。5.敏捷开发:这种开发模式适用于敏捷开发流程,可以在项目开发周期内频繁地进行需求变更和更新。然而,前后端混合开发模式也需要注意一些问题,例如接口不稳定可能导致前后端频繁修改,需要严格的接口文档和版本管理。此外,项目的复杂性和团队的规模也会影响这种开发模式的适用性。
前后端分离开发模式是一种软件开发方式,其中前端和后端的开发工作分开进行,彼此解耦,通过接口进行数据交互。这种模式旨在提高开发效率、降低耦合度,并允许不同团队专注于各自领域的开发。在前后端分离开发模式中,前端和后端开发人员可以使用不同的编程语言、框架和技术来进行开发。前端负责构建用户界面、交互和用户体验,后端负责处理业务逻辑、数据库操作和提供数据接口。主要特点包括:1. **松耦合**:前后端之间通过接口进行数据交互,实现了松耦合的架构,使得前后端团队可以独立开发和更新。2. **独立开发**:前端和后端可以同时进行开发,不会相互阻塞,从而加快项目的开发进度。3. **技术多样性**:前端和后端可以选择最适合自己的技术栈,使得团队可以根据需求灵活选择合适的工具。4. **提高效率**:前端和后端开发人员专注于各自领域的开发,提高了效率和专注度。5. **维护方便**:由于前后端分离,当需求变更或修复问题时,只需修改相应的模块,不会影响到整个系统。6. **适合团队合作**:不同团队可以并行开发,有助于团队协作和项目管理。然而,前后端分离也需要注意接口设计的合理性、数据传输的安全性以及接口文档的编写和维护等问题。同时,这种模式对项目的规划和架构设计有一定的要求,以确保前后端之间的协同顺畅。
为了在团队内部形成共识、防止个人习惯差异引起的混乱,我们需要找到一种大家都觉得很好的接口实现规范,而且这种规范能够让后端写的接口,用途一目了然,减少双方之间的合作成本-api接口:通过网络,规定了前后台信息交互规则的url链接,也就是前后台信息交互的媒介-https://www.baidu.com/books/--->JSON 格式数据---》接口 -Https://www.cnblogs.com/liuqingzheng/articles/17400599.html---》返回界面 -url和接口的区别:WEB API接口和一般的url链接还是有区别的,Web API接口简单概括有下面四大特点-1.url:长得像返回数据的url链接 https://api.map.baidu.com/place/v2/search -2.请求方式:get、post、put、patch、delete采用get方式请求上方接口-3.请求参数:json或xml格式的key-value类型数据 ak:6E823f587c95f0148c19993539b99295 region:上海 query:肯德基 output:json -4.响应结果:json或xml格式的数据 -https://api.map.baidu.com/place/v2/search?ak=6E823f587c95f0148c19993539b99295®ion=%E4%B8%8A%E6%B5%B7&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=json-典型的api接口长这样-url地址 -有请求方式 -携带参数 -返回格式是json,xml-前端不同编码格式:-urlencoded: body体中 :username=lqz&passWord=123 Django的request.POST取出值 -json: body体中 :{"username":"lqz","password":"123"} djanGo的request.POST取不出值 -fORM-data:body中格式固定:数据部分和文件部分--》request.POST能取出数据,取不出文件,文件都是从 '----------------------------789048583058585187025897\r\nContent-Disposition: form-data; name="username"\r\n\r\nlqz\r\n文件二进制-django中的文件对象和原来的文件对象-django:from django.core.files.uploadedfile import InMemoryUploadedFile -原生文件:_io.BufferedWriter -django中文件类没有继承原生文件类,但是有原生文件类所有方法-装饰器模版def warpper_request(func): def inner( *args, **kwargs): # 在执行被装饰函数前执行 res = func(*args, **kwargs) # 在执行被装饰函数后执行 return res return inner
1 前后端分离要写接口---》api接口---》接口测试工具postman2 restful规范是什么,如何来的?-一种定义Web API接口的设计风格,尤其适用于前后端分离的应用模式中 的规范 -Roy Fielding的博士论文提出的3 以后写接口,大致都要遵循一个规范,restful规范---》10条--》-1 数据的安全保障-》url链接一般都采用https协议进行传输--》它比http安全-2 接口特征表现--》url中带api标识 -https://api.baidu.com/books/ -https://www.baidu.com/api/books/ -3 多数据版本共存--》url中带版本信息 https://api.baidu.com/v1/bookshttps://www.baidu.com/api/v2/books -4 数据即是资源,均使用名词(可复数)-->前后台交互,交互的数据称之为资源 -数据即资源,前后端交互的数据称之为资源,url尽量使用名字 -https://127.0.0.1/api/v1/books/ -->表示对图书操作:增加,删除,查询,修改,都用这一个地址 -https://127.0.0.1/api/v1/get_all_books/ # 不符合restful规范 -https://127.0.0.1/api/v1/delete_books/# 不符合restful规范 -5 资源操作由请求方式决定-get 请求获取数据(获取所有,获取单条) -post 新增数据 -put 修改数据 -delete 删除数据 https://api.baidu.com/books - get请求:获取所有书 https://api.baidu.com/books/1 - get请求:获取主键为1的书 https://api.baidu.com/books - post请求:新增一本书书 https://api.baidu.com/books/1 - put请求:整体修改主键为1的书 https://api.baidu.com/books/1 - delete请求:删除主键为1的书 -6 请求地址中带过滤条件---》只针对于搜索所有接口https://api.example.com/v1/zoos?limit=10:指定返回记录的数量https://api.example.com/v1/zoos?offset=10:指定返回记录的开始位置https://api.example.com/v1/zoos?page=2&per_page=100:指定第几页,以及每页的记录数https://api.example.com/v1/zoos?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序https://api.example.com/v1/zoos?animal_type_id=1:指定筛选条件 -7 响应状态码(两层)-http响应状态码: 1xx,2xx,3xx,4xx,5xx:https://www.sohu.com/a/278045231_120014184 -404和403 和 405 -301和302 -1xx表示请求正在处理---》前端一般看不到 -2xx 表示请求处理成功--》经常看到 -201和200有什么区别 -3xx:重定向 -4xx:客户端错误 -5xx:服务端出错 -成功都返回200,而在响应体中带 状态码--->code不同公司就不一样 { "code": 101, "msg": "用户名或密码错误" } -补充一:Mysql 错误操作都会有个 数字(10060) 文字解释 -补充二: -https://open.weibo.com/wiki/Error_code -8 响应中带错误信息{ "code": 101, "msg": "用户名或密码错误" } -9 不同操作,返回格式符合如下标准GET /collection:返回资源对象的列表(数组) # [{name:西游记,price:19},{name:三国,price:19}] GET /collection/resource:返回单个资源对象 # {name:三国,price:19} POST /collection:返回新生成的资源对象 # {name:三国,price:19} PUT /collection/resource:返回完整的资源对象 # {name:三国演绎,price:19} DELETE /collection/resource:返回一个空文档 # ---》大家都这么做 { code:100 msg:查询成功 restult:[{name:西游记,price:19},{name:三国,price:19}] } -10 响应中带链接Hypermedia API,RESTful API最好做到Hypermedia,即返回结果中提供链接,连向其他API方法,使得用户不查文档,也知道下一步应该做什么{ "status": 0, "msg": "ok", "results":[ { "name":"肯德基(罗餐厅)", "img": "https://image.baidu.com/kfc/001.png" } ...]}
序列化: 数据转换格式序列化分两个阶段:-序列化:把我们识别的数据转换成指定的格式提供给别人 -反序列化:把别人提供的数据转换/还原成我们需要的格式序列化: 把我们识别的数据转换成指定的格式提供给别人。例如:我们在django中获取到的数据默认是模型对象,但是模型对象数据无法直接提供给前端或别的平台使用,所以我们需要把数据进行序列化,变成字符串或者json数据,提供给别人。反序列化:把别人提供的数据转换/还原成我们需要的格式。例如:前端js提供过来的json数据,对于python而言就是字符串,我们需要进行反序列化换成模型类对象,这样我们才能把数据保存到数据库中
基于django编写符合restful规范的接口了假设以 Book 表为例,写它的5个接口-1 查询所有 -2 新增一条 -3 修改一条 -4 删除一条 -5 查询一条 以下是使用原生django编写:########### book的接口写成CBV更好, 先用原生Django写''' http://127.0.0.1/books/ get查询所有 http://127.0.0.1/books/ post新增一条 http://127.0.0.1/books/id put新增一条 http://127.0.0.1/books/id delete新增一条 http://127.0.0.1/books/id get查询一条 '''from django.views import Viewfrom .models import Bookclass BookView(View): def get(self, request): books = Book.objects.all() # 查询出来的是queryset对象,不是列表 books_list = [] for item in books: books_list.append({'name': item.name, 'price': item.price}) res = {'code': 200, 'msg': '查询成功', 'data': books_list} return JsonResponse(res) def post(self, request): # 新增一条数据 name = request.POST.get('name') price = request.POST.get('price') if name and price: Book.objects.create(name=name, price=price) res = {'code': 200, 'msg': '数据添加成功'} else: res = {'code': 400, 'msg': '数据添加失败,请认真核对参数'} return JsonResponse(res)class BookDetailView(View): def put(self, request, pk): int_data_dict = json.loads(request.body) name = int_data_dict.get('name') price = int_data_dict.get('price') book = Book.objects.get(pk=pk) book.name = name book.price = price book.save() return JsonResponse({'code': 100, 'msg': '查询成功', 'data': {'name': book.name, 'price': book.price}}) def get(self, request, pk): book_obj = Book.objects.filter(pk=pk).first() if book_obj: res = {'code': 200, 'msg': f'图书id为{book_obj.pk}的数据查询成功', 'data': {'name': book_obj.name, 'price': book_obj.price}} else: res = {'code': 1006, 'msg': '暂无你查询的数据'} return JsonResponse(res) def delete(self, request, pk): book = Book.objects.filter(pk=pk).first() if book: book.delete() res = {'code': 200, 'msg': f'图书id为{pk}的数据查询删除成功'} else: res = {'code': 1007, 'msg': '你要删除的数据不存在'} return JsonResponse(res)注意:djangorestframework: drf, django的一个第三app---》方便我们快速实现符合restful规范的接口*****drf快速写接口**********使用步骤:1 安装模块 1 django 是2版本,用不了drf最新(适当降版本),他会卸载django---》装最新4.x 2 djagno 3.1.12 可以使用drf最新 -django:3.1.12 -drf:3.14.0 2 在app中注册 INSTALLED_APPS = [ 'rest_framework', # 一定不要忘了加 , ] 3 写路由 from rest_framework.routers import DefaultRouter router = DefaultRouter() router.reGISter('books', BookView, 'books') urlpatterns += router.urls 4 写视图类 from rest_framework.viewsets import ModelViewSet from .serializer import BookSerializer class BookView(ModelViewSet): queryset = Book.objects.all() serializer_class = BookSerializer 5 写序列化类 class BookSerializer(serializers.ModelSerializer): class Meta: model = Book fields = "__all__"
class User(models.Model): # char是定长,varchar是可变长 username = models.CharField(max_length=32) password = models.CharField(max_length=32)class Book(models.Model): name = models.CharField(max_length=64) price = models.IntegerField()
转换器: # str,匹配除了路径分隔符(/)之外的非空字符串,这是默认的形式 # int,匹配正整数,包含0。 # slug,匹配字母、数字以及横杠、下划线组成的字符串。 # uuid,匹配格式化的uuid,如 075194d3-6885-417e-a8a8-6c931e272f00。 # path,匹配任何非空字符串,包含了路径分隔符(/)(不能用?) path('books/' , BookView.as_view()),
来源地址:https://blog.csdn.net/weixin_44145338/article/details/132561322
--结束END--
本文标题: Web开发模式、API接口、restful规范、序列化和反序列化、drf安装和快速使用、路由转换器(复习)
本文链接: https://lsjlt.com/news/383251.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-03-01
2024-03-01
2024-03-01
2024-03-01
2024-03-01
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0