APIView และฟังก์ชัน @api_view

DRF lets you write endpoints as classes with APIView or as plain functions decorated with @api_view. Both speak the same JSON dialect.

APIView subclasses Django's View but gives you DRF's request parsing, content negotiation, and tidy response handling for free.

In an APIView you write a method per HTTP verb: get for reads, post for creates, and so on, keeping each action clearly separated.

Instead of HttpResponse, you return DRF's Response object, which renders to JSON or the browsable API based on the request.

DRF parses the body for you, so you read posted JSON from request.data as a normal Python dict, no manual decoding needed.

For simple endpoints the @api_view decorator turns an ordinary function into a DRF view, listing which HTTP methods it accepts.

You pass the verbs to the decorator. Any method not listed gets an automatic 405 Method Not Allowed, so you do not handle it yourself.

Function views use the very same DRF Response, so you can mix class and function styles in one project without friction.

Reach for @api_view when an endpoint is small and one-off; choose APIView when you want reusable, organized methods on a class.

Both styles let you pass status= to Response so clients get the right HTTP code, like 201 when you create something new.

Whether class or function, you get DRF parsing, responses, and status handling, the difference is mostly structure and personal taste.

What does @api_view do to a plain function?

You can build endpoints with class-based APIView or function-based @api_view, both returning a DRF Response. Pick the shape that fits. 🧩