Какие из методов http идемпотентны?

Идемпотентные методы HTTP

В HTTP-протоколе идемпотентность — это свойство метода, означающее, что многократное выполнение одного и того же запроса с одними и теми же данными должно приводить к одинаковому результату и состоянию сервера, как если бы запрос был выполнен только один раз.

Идемпотентные методы HTTP 1.1

Согласно спецификации RFC 7231, следующие методы считаются идемпотентными:

1. GET — предназначен только для получения данных. Не должен изменять состояние сервера.
2. HEAD — аналогичен GET, но возвращает только заголовки без тела ответа.
3. PUT — используется для полного обновления ресурса. Многократный вызов с одними и теми же данными должен оставлять ресурс в одинаковом состоянии.
4. DELETE — удаление ресурса. После первого успешного удаления последующие запросы должны возвращать одинаковый результат (обычно 404 или 410).
5. OPTIONS — получение информации о поддерживаемых методах для ресурса.
6. TRACE — диагностический метод, возвращающий полученный запрос.

Неидемпотентные методы

Основной неидемпотентный метод — POST. Каждый его вызов может создавать новый ресурс или вызывать разные побочные эффекты:

POST /articles HTTP/1.1
Content-Type: application/json

{
    "title": "Новая статья",
    "content": "Текст статьи"
}

Повторный вызов этого запроса создаст еще одну статью с тем же содержимым, что изменит состояние сервера.

Особые случаи и нюансы

PATCH метод

Метод PATCH технически не является идемпотентным по умолчанию, но может быть реализован как идемпотентный:

// Неидемпотентный PATCH - инкремент значения
PATCH /users/123 HTTP/1.1
Content-Type: application/json

{
    "op": "increment",
    "field": "login_count",
    "value": 1
}

// Идемпотентный PATCH - установка конкретного значения
PATCH /users/123 HTTP/1.1
Content-Type: application/json

{
    "op": "replace",
    "field": "login_count",
    "value": 42
}

Практическое значение идемпотентности

В Go-разработке понимание идемпотентности критично для:

1. Повторные запросы при сбоях сетевого соединения
2. Механизмы retry в клиентских библиотеках
3. Кэширование ответов
4. Обеспечение консистентности данных в распределенных системах

Пример безопасного повторения идемпотентного запроса в Go:

package main

import (
    "net/http"
    "time"
)

func safeRetry(client *http.Client, req *http.Request, maxRetries int) (*http.Response, error) {
    // Проверяем, можно ли безопасно повторять запрос
    if req.Method != http.MethodGet && 
       req.Method != http.MethodHead && 
       req.Method != http.MethodPut && 
       req.Method != http.MethodDelete {
        return client.Do(req)
    }
    
    var resp *http.Response
    var err error
    
    for i := 0; i < maxRetries; i++ {
        resp, err = client.Do(req)
        if err == nil && resp.StatusCode < 500 {
            return resp, nil
        }
        time.Sleep(time.Duration(i+1) * 100 * time.Millisecond)
    }
    
    return resp, err
}

Важные исключения и предостережения

1. Серверная реализация: Идемпотентность гарантируется только при корректной реализации сервера. Например, если PUT-метод увеличивает счетчик при каждом вызове, он нарушает идемпотентность.

2. Побочные эффекты: Даже идемпотентные методы могут иметь логирование или аудит, которые изменяются при каждом вызове, но это не считается нарушением, если основное состояние ресурса сохраняется.

3. Внешние системы: Если операция затрагивает внешние системы (отправка email, списание денег), даже GET-запрос может быть неидемпотентным.

Заключение

Понимание идемпотентности HTTP-методов — фундаментальный аспект проектирования RESTful API и веб-сервисов. В Go-экосистеме, где часто разрабатываются высоконагруженные и распределенные системы, правильное использование идемпотентных методов позволяет:

• Упростить обработку ошибок сети
• Уменьшить вероятность дублирования операций
• Повысить надежность системы в целом
• Корректно реализовывать стратегии повторных запросов

Разработчикам следует всегда проектировать API с учетом идемпотентности, особенно для методов, изменяющих состояние системы, и явно документировать случаи, когда обычно идемпотентные методы реализуются с неидемпотентным поведением.