More standardized status codes

[downdawn]

    200: '服务器成功返回请求数据',
    201: '新建或修改数据成功',
    202: '一个请求已经进入后台排队(异步任务)',
    204: '删除数据成功',
    400: '发出信息有误',
    401: '用户没有权限(令牌、用户名、密码错误)',
    403: '用户得到授权，但是访问是被禁止的',
    404: '访问资源不存在',
    425: '翻页超过限制',
    429: '查询超过限制',
    406: '请求格式不可得',
    410: '请求资源被永久删除，且不会被看到',
    500: '服务器发生错误',
    502: '网关错误',
    503: '服务不可用，服务器暂时过载或维护',
    504: '网关超时',
    ...

Use CustomCode more..

[wu-clan]

There are standard state code definitions in starlette, I'm not sure we're all going to reference it, perhaps create a similar file locally like CustomCode class

https://github.com/fastapi-practices/fastapi_best_architecture/blob/master/backend/app/common/response/response_code.py#L6
https://github.com/encode/starlette/blob/master/starlette/status.py

[downdawn]

Business code (CustomCode) and communication code (http)

https://www.v2ex.com/t/676678?p=1

[downdawn]

http state code: 400

body:

{
  "code": 40001,
  "msg": "验证码错误",
  "data": {}
}

[wu-clan]

My idea:

• For response information, we implement standard custom return code
• For http status, we use standard protocol code such as defined in Starlette, which mostly happens in exception blockers

[wu-clan]

Hi, @downdawn

Please check: #223

Please try to get this review done before the holidays or it will be postponed!

[downdawn]

response_base.success and response_base.fail are not enough

Query (GET requests): Typically use 200 OK (success) or 404 Not Found (not found).

Create (POST requests): Typically use 201 Created (success), 400 Bad Request (invalid request), or 409 Conflict (resource already exists).

Update (PUT or PATCH requests): Typically use 200 OK (success), 400 Bad Request (invalid request), or 404 Not Found (resource not found).

Delete (DELETE requests): Typically use 204 No Content (success), or 404 Not Found (resource not found).

200 returns data, 204 returns no data, and for successful updates, 204 is commonly used as well.

Asynchronous operations: For asynchronous operations, it's common to return 202 Accepted after accepting the request, indicating that the request has been accepted but processing is not yet complete. This is used in cases such as long-running tasks, queue processing, or lengthy batch processing.

[wu-clan]

This change we need to use fastapi internal JSONResponse implementation to return, because only it can modify the http status code, and to add the request parameter in each interface, used to pass the interface request method

A successful response might look like this：

@staticmethod
async def __response(
    *,
    request: Request,
    res: CustomResponseCode = None,
    data: Any | None = None,
    exclude: _ExcludeData | None = None,
    **kwargs
) -> JSONResponse:
    if data is not None:
        custom_encoder = {datetime: lambda x: x.strftime(settings.DATETIME_FORMAT)}
        kwargs.update({'custom_encoder': custom_encoder})
        data = jsonable_encoder(data, exclude=exclude, **kwargs)
    status_code = 200
    if request.method == MethodType.POST:
        status_code = 201
    elif request.method == MethodType.DELETE:
        status_code = 204
    return JSONResponse(content={'code': res.code, 'msg': res.msg, 'data': data}, status_code=status_code)

Error response, view:

fastapi_best_architecture/backend/app/common/exception/errors.py

Lines 3 to 8 in 5173ff7

	"""
	全局业务异常类
	业务代码执行异常时，可以使用 raise xxxError 触发内部错误，它尽可能实现带有后台任务的异常，但它不适用于**自定义响应状态码**
	如果要求使用**自定义响应状态码**，则可以通过 return await response_base.fail(res=CustomResponseCode.xxx) 直接返回
	""" # noqa: E501

What needs to be changed:

fastapi_best_architecture/backend/app/common/exception/exception_handler.py

Lines 96 to 98 in 5173ff7

	if isinstance(exc, BaseExceptionMixin):
	return JSONResponse(
	status_code=StandardResponseCode.HTTP_400,

[wu-clan]

While this change would make the status code very standard, some flexibility would be lost and would need to be considered and probably not implemented

[downdawn]

ok

[downdawn]

Hi @wu-clan
This is a fairly mainstream interface specification. Do you have any thoughts on it?

https://pro.ant.design/zh-CN/docs/request/#%E7%BB%9F%E4%B8%80%E6%8E%A5%E5%8F%A3%E8%A7%84%E8%8C%83

[wu-clan]

Not really, we currently use the simplest uniform return format, although ant popular, but I do not think it is the mainstream, and everyone or every company has their own implementation of the standard, the current format will be common to anyone, even if they were to modify it to their own standards, it wouldn't be complicated

[downdawn]

Hmm, traceId is more like a product of microservices