Сколько символов можно поместить в Query?

Сколько символов можно поместить в Query (URL Query Parameters)

Введение

Этот вопрос часто возникает при проектировании API. Ответ: "это сложно" и зависит от многих факторов.

Теоретический лимит

URL Length Limit:

Дифферентные ограничения по стандартам и браузерам:

HTTP specification:
  - RFC 3986: НЕ определяет лимит
  - Рекомендация: 2000 символов (для совместимости)

Веб-серверы:
  - Apache: 4000 символов (configurable)
  - Nginx: 4096 символов
  - IIS: 16,384 символов

Браузеры:
  - Chrome: ~32 KB
  - Firefox: ~65 KB
  - Safari: ~80 KB
  - Internet Explorer: 2,083 символов (очень старый!)

На практике:
  - Абсолютный минимум: 2000 символов (IE compatibility)
  - Рекомендуется: 4000-8000 символов
  - Safe: всегда <2000 символов

Query Parameters специфически

Query string = всё после ?

https://api.example.com/users?name=john&age=30&city=nyc
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                              Это query string

Лимит query parameters:

Oдин параметр:
  ?name=John Doe Smith Johnson → 50+ символов, OK
  
Много параметров:
  ?name=john&age=30&email=john@example.com&phone=123...
  → Может быстро вырасти
  
Массивы/Lists:
  ?ids=1,2,3,4,5,6,...1000
  → 1000 IDs = 5000+ символов
  → Может превысить лимит

Проблемы с длинными query strings

1. URL Encoding

Пробелы и спецсимволы кодируются:

Oisправный текст: "Hello World!"
Энкодированный: "Hello%20World%21"
                  (каждый спец-символ = +3 символа)

Этот эффект = практический лимит ещё ниже

Пример:
Параметр: "Description: Very Long Text!"
Энкодированный:
  "Description%3A%20Very%20Long%20Text%21"
  (исходный 31 → закодированный 41 символ)

2. Proxy/Load Balancer issues

Некоторые промежуточные серверы имеют свои лимиты:

Amazon ELB:
  - URL до 2KB
  - Query до 1KB

Cloudflare:
  - URL до 4KB
  - Большее = error 431 (Request Header Fields Too Large)

Custom proxies:
  - Могут быть любые лимиты

3. Logging issues

Серверные логи часто обрезают длинные URL:

Apache access log:
  По умолчанию логирует первые 8000 символов
  Большее: обрезано, потеряна информация

ELK (Elasticsearch):
  Может обрезать при индексации

Sentry (error tracking):
  Обрезает при сохранении ошибок

Case 1: Ошибка с длинным query string

Ситуация: API endpoint для поиска заказов по множеству фильтров.

Endpoint:
GET /api/orders?status=pending&customer_id=123&date_from=2026-01-01&date_to=2026-03-31&tags=vip,urgent,bulk,export&notes_contains=important&min_amount=100&max_amount=50000&...

Проблема: У нас запрос с 20+ параметрами. Total URL: 4500 символов.

Что случилось:
1. Frontend отправляет запрос
2. Chrome: OK (his 32KB limit)
3. Nginx пропускает (4096 limit достаточно)
4. Backend приложение: OK
5. Но... ELB (AWS Load Balancer): ОТКЛОНЯЕТ
   Error: 431 Request Header Fields Too Large
6. Клиент видит ошибку
7. Tech support: "API сломан?"
8. Я должен фиксить

Решение:

Переделал на POST с Body:

Вместо:
GET /api/orders?status=pending&customer_id=123&...(4500 chars)

Теперь:
POST /api/orders/search
Body: {
  "status": "pending",
  "customer_id": 123,
  "date_from": "2026-01-01",
  "date_to": "2026-03-31",
  "tags": ["vip", "urgent"],
  "notes_contains": "important",
  "amount_range": {
    "min": 100,
    "max": 50000
  }
}

Результат:

• No URL length issues
• Body может быть гораздо больше (часто 100MB+)
• Cleaner API
• Easier to read/maintain

Case 2: Pagination с длинными ID's

Ситуация: Pagination параметр ids который содержит список ID's

Оригинальный подход:
GET /api/items?ids=550e8400-e29b-41d4-a716-446655440000,
                    550e8401-e29b-41d4-a716-446655440001,
                    550e8402-e29b-41d4-a716-446655440002,
                    ...(100 IDs, каждый UUID = 36 символов)

Тotal URL: 3600+ символов

Проблемы:

1. Вклочен URL length limit
2. Очень некрасиво в логах
3. Кэширование усложняется (разные URL для разных наборов ID)

Решение:

Вариант 1: POST вместо GET

POST /api/items/batch
Body: {
  "ids": [
    "550e8400-e29b-41d4-a716-446655440000",
    "550e8401-e29b-41d4-a716-446655440001",
    ...
  ]
}

Вариант 2: Кэша список на backend

Приём:
1. POST /api/items/list-cache
   Body: {"ids": [...]}
   Response: {"cache_id": "abc123"}

2. GET /api/items?cache_id=abc123

Преимущества:
- GET-friendly
- Короткая URL
- Можно повторно использовать
- Cache ID = 10-20 символов

Вариант 3: Batch ID encoding

Сжать ID's:
Вместо: id1,id2,id3,...
Использовать: [массив индексов]

Пример:
ID's: uuid-1, uuid-2, uuid-3
Запрос: GET /api/items?batch=1,2,3
  (сервер знает какие UUID соответствуют индексам)

Best practices

1. Используй POST для сложных queries

❌ GET /api/search?q=...&filters=...&sort=... (2000+ chars)
✓ POST /api/search
  Body: {query, filters, sort}

2. Кодируй список ID's в body, не в URL

❌ GET /api/items?ids=id1,id2,id3,...id100
✓ POST /api/items/batch
  Body: {ids: [id1, id2, ...]}

3. Используй pagination (cursor-based)

❌ GET /api/items?offset=0&limit=100
   GET /api/items?offset=100&limit=100
   (Может быть много параметров)

✓ GET /api/items?limit=100
  Response: {items: [...], next_cursor: "abc123"}
  
  Следующая: GET /api/items?limit=100&cursor=abc123
  (Только один параметр, одна URL)

4. Если всё же GET, то <2000 символов

Проверка при создании URL:

if (url.length > 2000) {
  throw new Error("URL too long, use POST instead");
}

5. URL encode всё правильно

✓ Хорошо:
let query = "Hello World";
let encoded = encodeURIComponent(query);
// Result: "Hello%20World"

❌ Плохо:
let url = `?query=Hello World`;  // Невалидный URL

Специфичные ограничения по сервисам

Google Cloud (GCP)

URL length: 8000 символов (мягко)
Hard limit: 32KB
Best practice: <2000

AWS

ELB: 4KB (вернёт 431 ошибку)
API Gateway: 10KB
Best practice: <2000

Azure

Application Gateway: 8000 символов
Best practice: <2000

Traditional SQL Databases

При использовании URL параметров для SQL
URI length limit можно превысить

Пример проблемы:
GET /api/users?ids=1,2,3,4,...,10000
→ 10k ID = очень длинный URL
→ Может не спарситься

Как рассчитать URL length

// Function to estimate URL length
function estimateUrlLength(params) {
  let baseUrl = "https://api.example.com/endpoint";
  let queryString = "?";
  
  for (let key in params) {
    let value = params[key];
    if (Array.isArray(value)) {
      // For arrays, estimate worst case
      value = value.join(",");
    }
    
    // Encode to account for URL encoding
    let encoded = encodeURIComponent(value);
    queryString += `${key}=${encoded}&`;
  }
  
  let totalUrl = baseUrl + queryString;
  return totalUrl.length;
}

// Usage
let params = {
  search: "Hello World",
  filters: {type: "article"},
  ids: [1, 2, 3, 4, 5]
};

let length = estimateUrlLength(params);
console.log(`URL length: ${length} characters`);

if (length > 2000) {
  console.warn("URL too long! Consider using POST instead.");
}

Мой personal checklist

При дизайне API с query параметрами:

☐ Сколько параметров максимум?
  → Если >5: рассмотри POST

☐ Какие самые длинные значения?
  → UUID = 36 chars
  → ISO date = 10 chars
  → Email = variable, до 254 chars

☐ Сумма длин всех параметров?
  → Calculate worst case
  → Multiply by ~1.3 (для URL encoding)
  → Должна быть < 2000 символов

☐ Нужно ли кэшировать результаты?
  → Если yes: используй POST (с cache ID)
  → Если no: OK с GET (если <2000)

☐ Логирование?
  → Будут ли логи обрезаны?
  → Повлияет ли на debugging?

Вывод

Для query strings:

• Абсолютный лимит: 2000 символов
• Рекомендуется: <1500 символов (со всеми параметрами)
• Safe: всегда тестируй < 2000

Когда вероятен перевыс:

• Множество ID's в один параметр
• Длинные текстовые значения
• Много разных параметров

Решение:

• Используй POST вместо GET
• Паджинируй результаты
• Кэши и используй ID вместо данных
• Сжимай data (JSON вместо XML)

Практический совет: Если сомневаешься — используй POST. Body может быть намного больше, и нет этих неприятных ограничений URL'а.