Почему сервер выдает четыреста пятый статус код?

Почему сервер возвращает статус-код 405?

Статус-код 405 Method Not Allowed — это ответ сервера, указывающий, что метод HTTP-запроса (например, GET, POST, PUT, DELETE) известен серверу, но не поддерживается для целевого ресурса. В отличие от 404 (ресурс не найден), сервер "понимает" запрос, но намеренно отклоняет его из-за ограничений, связанных с методом.

Основные причины возникновения 405

• Неподдерживаемый метод для конкретного эндпоинта (API endpoint).

    *   Пример: попытка отправить `POST`-запрос на эндпоинт, предназначенный только для чтения данных (`GET`).

```http
POST /api/v1/books/123 HTTP/1.1
Host: example.com
```

    Если `/api/v1/books/123` предназначен только для получения информации о книге (GET), сервер ответит 405.

• Ограничения, заданные на уровне веб-сервера (Nginx, Apache).

    *   Конфигурация сервера может глобально запрещать определенные методы для директории или расширения файла.

```nginx
# Пример конфигурации Nginx, запрещающей POST для статических файлов
location ~* \.(html|css|js)$ {
    limit_except GET HEAD {
        deny all;
    }
}
```

• Ограничения в коде приложения (бэкенд-фреймворк: Spring, Django, Express.js).

    *   Роутер или контроллер явно определяет, какие методы разрешены.

```python
# Пример на Django REST Framework
from rest_framework.views import APIView
from rest_framework.response import Response

class BookDetailView(APIView):
    # Разрешены только GET и PATCH
    http_method_names = ['get', 'patch']

    def get(self, request, pk):
        return Response(...)

    def patch(self, request, pk):
        return Response(...)
```

    Запрос `DELETE` или `PUT` к этому представлению вызовет 405.

• Отсутствие обработчика для метода в коде.

    *   Серверное приложение не содержит функции или метода для обработки входящего запроса с данным HTTP-глаголом.

• Проблемы с CORS (Cross-Origin Resource Sharing).

    *   В рамках **предварительного запроса (preflight request)** браузер отправляет запрос методом `OPTIONS` для проверки разрешенных методов. Если сервер не корректно обрабатывает `OPTIONS` или не включает ожидаемый метод в заголовок `Access-Control-Allow-Methods`, это может привести к 405.

Как анализировать и устранять проблему (с точки зрения QA)

1. Анализ запроса:

    *   Проверьте **HTTP-метод** (GET, POST и т.д.) в инструментах разработчика (DevTools → Вкладка Network) или в логах.
    *   Убедитесь, что метод соответствует документации API (Swagger/OpenAPI).

1. Проверка ответа сервера:

    *   Ответ с кодом 405 **должен включать обязательный заголовок `Allow`**, в котором перечислены разрешенные для данного URL методы.

```http
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/json

{
    "error": "Method 'POST' not allowed."
}
```

    *   Отсутствие заголовка `Allow` — признак некачественной реализации со стороны сервера.

1. Сравнение с эталоном:

    *   Свериться со спецификацией API. Возможно, метод устарел или вы ошиблись в выборе эндпоинта.

1. Воспроизведение и локализация:

    *   Воспроизведите проблему с помощью инструментов для тестирования API (Postman, cURL).

```bash
curl -X PUT https://api.example.com/resource \
     -H "Content-Type: application/json" \
     -d '{"data": "value"}'
```

    *   Определите уровень возникновения ошибки: глобальная конфигурация сервера, конкретный роут в приложении или проблема CORS.

1. Тестирование граничных случаев:

    *   Проверьте корректность обработки **метода `OPTIONS`** (для CORS).
    *   Проверьте реакцию на **нестандартные или устаревшие методы** (например, `COPY`, `LINK`).
    *   Убедитесь, что для ресурса, поддерживающего несколько методов (GET, POST, DELETE), заголовок `Allow` возвращает полный список.

Роль QA-инженера при работе с 405

Инженер по качеству должен не только констатировать факт ошибки, но и проанализировать ее корректность:

• Является ли такой ответ ожидаемым поведением согласно требованиям?
• Корректно ли формируется ответ сервера (есть заголовок Allow, понятное тело ошибки)?
• Не маскирует ли код 405 другую проблему (например, ошибку аутентификации 401/403 из-за неправильной конфигурации)?
• Воспроизводима ли ошибка на всех необходимых окружениях (stage, production)?

Понимание семантики кода 405 позволяет эффективно взаимодействовать с разработчиками, составляя точные и информативные баг-репорты, и проводить более глубокое тестирование RESTful API.