Add validation for decorator order with @api_view

[kernelshard]

Fixes #9596

This PR adds validation to detect when API policy decorators (@permission_classes, @renderer_classes, etc.) are applied in the wrong order with @api_view.

Problem

When policy decorators are applied after @api_view (i.e., placed above it in code), the policy settings are silently ignored. This happens because:

• If policy decorators are applied after @api_view, they set attributes on the already-created view function, not the original function

Solution

Added a _check_decorator_order() helper that:

• Detects when a decorator is applied to a view function (result of APIView.as_view())
• Raises a clear TypeError with the correct decorator order
• Applied to all 9 policy decorators

Tests

Added 9 comprehensive tests covering all policy decorators to ensure they properly validate ordering.

[Copilot]

Pull Request Overview

This PR adds validation to ensure API policy decorators are applied in the correct order relative to the @api_view decorator. The feature prevents a common mistake where developers apply policy decorators after @api_view, which silently fails to work as expected.

• Introduced _check_decorator_order() helper function to detect incorrect decorator ordering
• Added order validation to all nine API policy decorators
• Comprehensive test coverage for all affected decorators

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
rest_framework/decorators.py	Added _check_decorator_order() validation function and integrated it into all API policy decorators to raise TypeError when applied after @api_view
tests/test_decorators.py	Added nine test cases to verify that each API policy decorator raises TypeError when incorrectly applied after @api_view

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The error message shows the decorators in the wrong order. When decorators are stacked, they are applied bottom-to-top, so @api_view should be on top and @{decorator_name} should be below it. The example currently shows:

@api_view(['GET'])
@{decorator_name}(...)
def my_view(request):
    ...

But this is the incorrect order being warned against. It should be:

@{decorator_name}(...)
@api_view(['GET'])
def my_view(request):
    ...

Suggested change

	f" @api_view(['GET'])\n"
	f" @{decorator_name}(...)\n"
	f" @{decorator_name}(...)\n"
	f" @api_view(['GET'])\n"

[kernelshard]

The decorator needs to go below @api_view, just as the docs show—this way, DRF reads the attribute properly and permissions work.
Our tests confirm the documented order is correct; error is raised only if you swap them.

[auvipy]

I will get back to you on saturday morning

[browniebroke]

Ok, Copilot is wrong here, but that might be a symptom that "applied before" is a bit ambiguous in this case. The docs are actually using the term "after":

These must come after (below) the @api_view decorator

The docs refer to the order the decorators appear in the code: as we read top to bottom the order is swapped vs how they are applied by the code (bottom to top).

Understanding how decorators are applied by the language is important, but less experience people might not know it, and therefore won't understand the error message.

I'd rather make the language of the error message closer to what we have in the docs.

[browniebroke]

Ok, Copilot is wrong here, but that might be a symptom that "applied before" is a bit ambiguous in this case. The docs are actually using the term "after":

These must come after (below) the @api_view decorator

The docs refer to the order the decorators appear in the code: as we read top to bottom the order is swapped vs how they are applied by the code (bottom to top).

Understanding how decorators are applied by the language is important, but less experience people might not know it, and therefore won't understand the error message.

I'd rather make the language of the error message closer to what we have in the docs.

[browniebroke]

We don't need the f prefix on lines where there is nothing to interpolate

[kernelshard]

@browniebroke Thanks for the review! I've updated the error message to address it.

The error message now:

@permission_classes must come after (below) the @api_view decorator. The correct order is:

@api_view(['GET'])
@permission_classes(...)
def my_view(request):
    ...