Как правильнее писать запрос к API await fetch?

Часто возникающий вопрос у js-программистов: как правильнее писать запрос к API, указывать прямую ссылку на файл обработчика или использовать относительные урлы?

Давайте рассмотрим, какие преимущества и недостатки каждого способа:

1 способ

await fetch( '/api/posts',{...} )

2 способ

await fetch( '/api/posts.php',{...} )

Выбор между двумя способами зависит от архитектуры вашего API и серверной реализации. Ниже сравнение подходов, их преимуществ и недостатков:

1 способ — await fetch(‘/api/posts’, {…}) (без расширения .php)

Преимущества:

  • Чистота и RESTful-стиль:
    URL без расширений (.php, .asp и т.д.) соответствует принципам REST API и чистой архитектуры. Клиент не знает о внутренней реализации сервера (например, что используется PHP).
  • Гибкость и масштабируемость:
    Вы можете легко сменить серверную технологию (например, перейти с PHP на Node.js) без изменения клиентского кода.
  • Безопасность:
    Скрытие технологического степа (например, .php) снижает вероятность целенаправленных атак, ориентированных на известные уязвимости PHP.
  • Кэширование и SEO:
    Короткие URL без расширений лучше обрабатываются прокси-серверами, CDN и поисковыми системами.

Недостатки:

  • Требует серверной настройки:
    Для работы URL без .php нужно настроить сервер (например, через mod_rewrite в Apache или try_files в Nginx) для перенаправления запросов к PHP-скрипту.
  • Сложность отладки:
    Если сервер не настроен правильно, запросы могут возвращать 404 ошибки, и диагностика проблемы потребует проверки серверной конфигурации.

2 способ — await fetch(‘/api/posts.php’, {…}) (с расширением .php)

Преимущества:

  • Простота настройки:
    Не требует дополнительных правил для сервера — запрос напрямую обрабатывается PHP-скриптом.
  • Прозрачность:
    Для небольших проектов или монолитных приложений прямое указание .php может быть более понятным для разработчиков.

Недостатки:

  • Технологическая привязка:
    Клиентский код становится зависимым от серверной технологии. Смена языка (например, с PHP на Python) потребует изменения URL во всех запросах.
  • Уязвимость к атакам:
    Злоумышленники могут использовать расширение .php для целенаправленных атак (например, LFI-уязвимости).
  • Хуже масштабируется:
    В больших проектах URL с расширениями выглядят менее профессионально и усложняют поддержку.

Какой из способов написания запроса выбрать?

  • Используйте /api/posts (без расширения), если:
    • Вы стремитесь к RESTful-архитектуре.
    • Хотите скрыть детали реализации от клиента.
    • Планируете масштабировать проект или менять серверную технологию.
    • Настраиваете сервер правильно (например, через mod_rewrite).
  • Используйте /api/posts.php (с расширением), если:
    • Проект небольшой и не требует долгосрочной поддержки.
    • Вы не хотите тратить время на настройку сервера.
    • Клиентский код и серверная логика тесно связаны (например, монолит).

Пример серверной настройки (Apache)

Для работы /api/posts с PHP-скриптом добавьте в .htaccess:

RewriteEngine On

RewriteRule ^api/posts$ /api/posts.php [L]

Вывод

Лучшая практика — использовать URL без расширений (например, /api/posts), так как это обеспечивает гибкость, безопасность и соответствие современным стандартам API-разработки. Расширение .php следует оставить только для легаси-систем или простых проектов без амбииций на масштабирование.