Features: Support same logic as DjangoViewSet

[yezz123]

• Class Based Views: In Django, views are the heart of the application. Class Based Views (CBVs) are a way to define views as classes rather than functions. This provides a number of benefits such as better code organization, reusability, and the ability to use mixins to add common functionality. There are several types of CBVs available in Django including APIViews, GenericViews, and ViewSets.

  • APIViews: These views are designed specifically for building RESTful APIs. They provide features like parsing request data, rendering responses, and handling common API errors. You can subclass the APIView to create your own custom views.

  • GenericViews: These views provide some common functionality for CRUD operations. You can use them to quickly create views for listing, creating, updating, and deleting objects. They are designed to be flexible and customizable.

  • ViewSets: ViewSets are similar to GenericViews but provide even more flexibility. They allow you to define a set of related views for a particular model or resource. You can define different actions for different HTTP methods like GET, POST, PUT, PATCH, and DELETE.

• Openapi id simplification: OpenAPI is a specification for building APIs. It provides a way to describe the structure of the API and the endpoints it exposes. One of the challenges with OpenAPI is that it can be verbose and difficult to read. OpenAPI ID simplification is a way to simplify the structure of OpenAPI files to make them easier to work with.

• 'Smart' and fast serialization using orjson: Serialization is the process of converting data from one format to another. In Django, serialization is used to convert Python objects to JSON format for use in APIs. orjson is a fast and efficient JSON serializer that can be used with Django. It provides some additional features like automatic serialization of date and datetime objects.

• Http Problem Details implementation: HTTP Problem Details is a standard way of representing errors in APIs. It provides a structured way of describing errors including a type, title, and detail. This makes it easier for API consumers to understand what went wrong and how to fix it. Django provides built-in support for HTTP Problem Details.

• Automatic prometheus metrics exporter: Prometheus is a monitoring system and time series database. It provides a way to collect and store metrics from applications. The prometheus-client library provides a way to export metrics from Django applications. The exporter can be configured to automatically collect metrics and make them available to Prometheus.

• Pluggable healthcheck helper: Health checks are a way to monitor the health of an application. They can be used to check if the application is running correctly and if there are any issues that need to be addressed. Django provides a pluggable health check framework that makes it easy to add health checks to an application. You can use the framework to create custom health checks and configure them to run at regular intervals.

[wu-clan]

For the other parameters of the request method，need support?

[yezz123]

Certainly, I would be pleased 🙏🏻

I'm considering implementing an approach akin to Django's. This logic modification will undoubtedly affect the code, particularly with using Serializer in conjunction with Pydantic , and also utilizing orjson for rapid serialization.

something like this for example

from typing import Optional, List
from uuid import UUID

from fastapi_class import APIViewSet, Serializer

class PersonSchema(Serializer):
    id: UUID
    name: str
    age: int


persons = {}


class MyView(APIViewSet):
    serializer = PersonSchema

    async def list(self, *args, **kwargs) -> List[PersonSchema]:
        return list(persons.values())

    async def create(self, person: PersonSchema) -> PersonSchema:
        persons[person.id] = person
        return person

    async def retrieve(self, id: UUID) -> Optional[PersonSchema]:
        return persons.get(id)

    async def update(self, person: PersonSchema):
        persons[person.id] = person

    async def destroy(self, id: UUID) -> None:
        persons.pop(id, None)

[wu-clan]

We've had some discussions here, but of course, just our own thoughts：fastapi-practices/fastapi_best_architecture#2

And comments from pr in #105 (comment)

[yezz123]

Migrating this to be in another project 👍🏻