В этой статье мы рассмотрим, что такое JSONP, его недостатки и некоторые альтернативы JSONP.
Возможно, вы столкнулись с ситуациями, когда вы выполняете вызов API из одного источника в другой. Например, у нас есть страница, обслуживаемая с localhost: 3000, которая вызывает API с localhost: 8000.
Примечание. Мы будем называть localhost: 3000 нашим клиентским сервером. Мы будем называть localhost: 8000 нашим API-сервером.
Но мы видим эту пугающую ошибку.
Это защищает нас Политика одного и того же происхождения. Эта политика ограничивает взаимодействие ресурсов из одного источника с ресурсами из другого источника. Это важный механизм безопасности в браузере. Но есть случаи, когда мы хотим делать запросы из разных источников к доверенным ресурсам.
JSONP (JSON с заполнением) позволяет решить эту проблему с политикой одинакового происхождения. Давайте посмотрим, как появился JSONP.
Техническое погружение
Мы можем запустить код JavaScript внутри нашего HTML-файла с тегами <script>.
Мы можем переместить наш код JavaScript в отдельный файл JavaScript и ссылаться на него с помощью нашего тега сценария. Наша веб-страница теперь выполняет внешний сетевой вызов для файла JavaScript. Но функционально все работает так же.
Файл Javascript не обязательно должен иметь расширение js. Браузер будет интерпретировать контент как JavaScript, если Content-Type ответа - JavaScript. (text/javascript, application/javascript).
Большинство серверов позволяют вам устанавливать тип контента. В Экспрессе вам нужно:
Тег <script> может ссылаться на URL без расширения js.
Теги скриптов не ограничиваются Политикой одинакового происхождения. Существуют и другие теги, такие как теги <img> и <video>, которые не ограничиваются Политикой одинакового происхождения. Таким образом, наш JavaScript может иметь другое происхождение.
Код внутри файла JavaScript имеет доступ ко всему, что находится в области видимости. Вы можете использовать функции, определенные ранее в вашем HTML-файле.
Вы можете передавать аргументы, как при обычном вызове функции.
В приведенном выше примере мы передали жестко запрограммированную строку. Но мы также можем передавать данные из базы данных. Наш сервер API может создать файл JavaScript с этой динамической информацией.
Вот что такое JSONP. Вместо использования fetch или XMLHttpRequest для вызова API для получения данных мы использовали тег <script>. Поскольку мы использовали тег <script>, мы смогли обойти политику одинакового происхождения.
Как я уже упоминал выше, JSONP означает JSON с заполнением. Что означает набивка? Обычные ответы API возвращают JSON. В ответах JSONP мы возвращаем ответ JSON, окруженный (или дополненный) функцией JavaScript.
Большинство серверов позволяют вам указать имя вашей функции заполнения.
Сервер принимает имя вашей функции заполнения в качестве запроса. Он вызывает вашу функцию заполнения с данными JSON в качестве аргумента.
Вы не ограничены передачей имен функций в качестве обратного вызова. Вы можете передать встроенный JavaScript в свой запрос.
Я не придумал причины для этого.
Альтернативы использованию JSONP
Официальной спецификации JSONP нет. Я думаю о JSONP как о взломе.
<script> теги могут отправлять только запросы GET. Таким образом, JSONP может делать только запросы GET.
Совместное использование ресурсов между разными источниками имеет официальную спецификацию и является предпочтительным способом обойти политику одного происхождения.
Вы можете включить совместное использование ресурсов между источниками, добавив заголовок в наш ответ.
Это означает, что все источники могут использовать этот ресурс, не опасаясь Политики одинакового происхождения.
Однако иногда у вас нет контроля над серверным кодом. Вы не сможете включить заголовок Access-Control-Allow-Origin. Альтернативное решение - сделать так, чтобы ваш собственный прокси-сервер выполнял за вас запрос на другой источник. Политика Same-Origin применяется только к браузеру. Серверы могут делать запросы из разных источников.
Вопросов? Комментарии? Пожалуйста, оставьте сообщение ниже.
