fastapi tests
from typing import Union
from fastapi import FastAPI
app = FastAPI()
@app.get("/get")
def get_test():
return {"method": "get方法"}
@app.post("/post")
def post_test():
return {"method": "post方法"}
@app.put("/put")
def put_test():
return {"method": "put方法"}
@app.patch("/patch")
def patch_test():
return {"method": "patch方法"}
@app.delete("/delete")
def delete_test():
return {"method": "delete方法"}
@app.options("/options")
def options_test():
return {"method": "options方法"}
@app.head("/head")
def head_test():
return {"method": "head方法"}
@app.trace("/trace")
def trace_test():
return {"method": "trace方法"}
# 02 多种请求测试
import uvicorn, asyncio
if __name__ == '__main__':
# uvicorn.run("f02mufun:app", host="127.0.0.1", port=8000, reload=True)
config = uvicorn.Config(app, host='0.0.0.0', port=8000)
server = uvicorn.Server(config)
asyncio.run(server.serve())
|
|
||||||||||||||||||||||||
|
HTTP（超文本传输协议）是互联网上应用最为广泛的网络协议之一，用于客户端和服务器之间的通信。在HTTP协议中，
GET 和 POST 是两种最常见的请求方法，它们各自有不同的用途和特点。1. GET 请求GET 请求用于从服务器获取资源，是最常用的HTTP方法之一。特点
应用场景
示例请求：
响应：
2. POST 请求POST 请求用于向服务器提交数据，通常用于创建或更新资源。特点
应用场景
示例请求：
响应：
GET 和 POST 的主要区别表格
总结
|
|
||||||||||||||||||||||||
Content-Type 是 HTTP 协议中的一个非常重要的头部字段，用于指示请求或响应中数据的媒体类型（MIME 类型）。它告诉服务器或客户端如何解析和处理请求或响应体中的数据。理解 Content-Type 的作用和常见类型对于开发 Web 应用和进行网络通信至关重要。1.
|
|
||||||||||||||||||||||||
| 没有响应头
|
增加响应头
|
||||||||||||||||||||||||
# 实现websocket 服务端，遵循http协议
import socket
socket_server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
socket_server.bind(('localhost', 8000))
socket_server.listen(5)
while True:
conn, addr = socket_server.accept()
print('Connected by', addr)
# while True:
data = conn.recv(1024)
if not data:
break
print('Received client data:\n', data)
# conn.sendall(data)
conn.sendall(b'HTTP/1.1 200 OK\r\nserver:test\r\n\r\nhello world') # 发送响应数据
conn.close()
|
|
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
RESTful（Representational State Transfer，表述性状态转移）是一种基于网络的软件架构风格，用于设计网络应用程序，使其能够通过标准的 HTTP 协议与资源进行交互。它强调以资源为中心，通过统一的接口和标准的 HTTP 方法来操作资源。
RESTful 的核心概念1. 资源（Resource）资源是 RESTful 架构中的核心概念，它是网络上的一个实体或可寻址的组件。资源可以通过 URI（Uniform Resource Identifier，统一资源标识符）来唯一标识。例如：
每个资源都有一个唯一的 URI，例如：
2. 资源的表述（Representation）资源的表述是资源的某种表现形式，通常是数据格式化的结果。常见的表述格式包括：
例如，一个用户资源的 JSON 表述可能如下：
JSON
3. 状态转移（State Transfer）状态转移是指客户端通过与资源的交互来改变资源的状态。客户端通过发送 HTTP 请求来获取资源的当前状态或修改资源的状态。状态转移是通过标准的 HTTP 方法实现的，例如：
4. 无状态（Stateless）RESTful 架构要求每个请求从客户端到服务器都包含所有必要的信息来理解和处理请求。服务器不会存储任何客户端请求之间的状态信息。这意味着每个请求都是独立的，服务器不会依赖于之前的请求状态。
RESTful 架构的约束条件RESTful 架构遵循以下六个约束条件，这些约束条件共同定义了 RESTful 架构的风格：
1. 统一接口（Uniform Interface）统一接口是 RESTful 架构的核心。它定义了客户端和服务器之间交互的规则，使得不同的客户端可以使用相同的接口与资源进行交互。统一接口包括以下四个方面：
2. 无状态（Stateless）每个请求都包含所有必要的信息来理解和处理请求。服务器不会存储任何客户端请求之间的状态信息。客户端可以保持状态，但服务器不会依赖于这些状态。
3. 可缓存（Cacheable）为了提高效率，RESTful 架构允许响应被缓存。如果响应是可缓存的，客户端可以直接使用缓存的响应，而无需再次请求服务器。服务器需要明确指定响应是否可以被缓存。
4. 分层系统（Layered System）RESTful 架构允许使用分层系统，客户端通常不知道它们是直接与服务器交互，还是与中间层（如代理、网关）交互。分层系统可以提高系统的可扩展性和安全性。
5. 统一的资源管理（Uniform Resource Management）资源的管理是通过标准的 HTTP 方法来实现的，例如：
6. 超媒体作为应用状态的引擎（HATEOAS）客户端通过超媒体链接动态发现可用的资源和操作。这意味着客户端不需要提前知道所有可用的资源和操作，而是可以通过服务器提供的链接动态发现。
RESTful API 的设计原则1. 资源的命名
2. 使用标准的 HTTP 方法
3. 状态码使用标准的 HTTP 状态码来表示请求的结果：
4. 超媒体链接在响应中包含超媒体链接，使客户端能够动态发现可用的资源和操作。例如：
JSON
RESTful API 的示例以下是一个简单的 RESTful API 示例，用于管理用户资源：
1. 获取用户列表http
响应：
JSON
2. 创建新用户http
响应：
http
3. 获取特定用户http
响应：
JSON
4. 更新特定用户http
响应：
http
5. 删除特定用户http
响应：
http
RESTful 架构的优点
RESTful 架构的缺点
总结RESTful 架构是一种面向资源的架构风格，通过统一接口和标准的 HTTP 方法来操作资源。它强调简单性、可扩展性和灵活性，适用于构建现代的网络应用程序。通过遵循 RESTful 的设计原则，可以设计出高效、可维护的 API。
|
11
|
||||||||||||||||||||||||
浙公网安备 33010602011771号