предисловие
К чему я это пишу, раньше задавал эти вопросы в интервью, и с моей личной точки зрения, изучение фронтенда — это на самом деле замыкание, прототип и т. д. Написано плохо, но про взаимодействие данных. Очень мало.В нашем деле взаимодействие с данными не меньшинство.Статью организую для всех,и для себя тоже.Надеюсь вам понравится и вы обратите внимание.GitHub
ajax
что такое аякс
На самом деле, когда дело доходит до ajax, все знакомы с ним, но я представлю его здесь подробно, чтобы заложить основу для моего следующего поста в блоге, посвященного взаимодействию с данными. JavaScript и XML (Асинхронный javascript и XML), почему появляется такая технология, потому что фронтенд часто имеет такой спрос, нам нужно обновлять только локально, а когда нам не нужно целое обновление, рождается такая технология ajax , Как именно это достигается, мы объясним ниже.
Основной процесс реализации ajax
На самом деле, я уже видел извращенный вопрос на собеседовании с просьбой написать нативный ajax самостоятельно.Если вы попросите меня проверить интерфейс, я могу его написать, но я не могу этого сделать, если вы позволите мне написать его по умолчанию. , потому что теперь я в основном использую инкапсуляцию jquery.Ajax действительно хорошо упакован, поэтому нам нужно только понять основной процесс реализации Ajax, я думаю, этого достаточно для начинающих студентов, таких как я.
Основной процесс ajax:
- Сценарий js страницы создает экземпляр объекта XMLHttprequest.
- Установите URL-адрес, предоставленный сервером, необходимые параметры запроса, функции обратного вызова и т. д.
- Инициировать запрос к серверу, а сервер обрабатывает запрос и возвращает результат на страницу
- Запустите ранее заказанную функцию обратного вызова, чтобы получить данные
То же самое верно и для процесса ajax для достижения частичного обновления, потому что мы можем использовать ajax для получения небольшого количества данных, связанных с этой частью, с сервера, а затем использовать эту часть данных для обновления страницы.
отслеживаемость ajax
На самом деле, ajax был предложен в статье, опубликованной Джесси Джеймсом Гарреттом из Google в 2005 г. Он основан на XMLHttp. XMLHttp был предложен Microsoft в 1998 г. Google использует ajax для разработки таких продуктов, как Google Maps. опубликовано в статье. На самом деле, ajax был создан для сложных приложений, таких как Google Maps. Однако я хочу поговорить о побочном продукте ajax — отправке форм.
Применение ajax при взаимодействии с данными
Я думаю, что ajax используется для взаимодействия с данными. Для начинающих, таких как я, я должен понять два момента. Один из них — разница между GET и POST. Вы можете комбинировать спецификацию промисов, чтобы увидеть, как инкапсулируется ajax jquery, и т. напишите об этом. Я планирую позже опубликовать спецификацию промиса, и обобщить некоторые новые методы взаимодействия с данными, такие как fetch. , для примера ajax-приложения:
$.ajax({
type: "post", //数据传输的方法
url: ..., //一般这里会是后端给你的接口路径
data: {data},//这里是一个提交的数据内容
success: function(){} //成功后进行的操作
error: function(){} //数据审核不通过，后端一般会返回false然后进行的操作Разница между GET и POST
Сталкиваясь с чем-то, мы должны сначала проверить документацию, уточнить основные понятия, а затем начать анализировать плюсы и минусы.
- основная концепция
На самом деле, разницу между ними можно четко увидеть в объяснении MDN:
Метод HTTP GET запрашивает указанный ресурс. Запросы с использованием GET следует использовать только для получения данных.
Метод HTTP POST отправляет данные на сервер.
- безопасность
Что касается безопасности двух, то в этом нет никаких сомнений, но вы знаете только, что POST более безопасен, чем GET, но вы не знаете, почему?
Немного более глубокое понимание обнаружит, что http-запрос метода get выглядит так:
Ваши параметры будут склеены с url и потом переданы, так что будет другая проблема, параметры все видны, как и на скриншоте, который я сделал, но POST отличается
Немного нарисовано, т.к. интерфейс фирменный, за url метода POST не следуют никакие параметры, POST помещается в тело запроса (это от W3C)
- закладка
Получить можно использовать в качестве коллекции закладки, потому что параметры будут пишется на URL, пост не может
- история
Параметры GET-запроса можно сохранить в истории браузера, а POST-нет — причина в том, что один параметр вклеивается в url, а другой — нет.
- ограничения на длину данных
Хочу поговорить об этом моменте.Откуда берется ограничение на длину данных GET, или пункт упомянутый выше.Параметры GET вклеены в URL.По идее параметры в URL можно удлинять до бесконечности, но это неизбежно приведет к тому, что это ложится тяжелым бременем на браузеры и серверы, поэтому в отрасли существует неписаное правило: в большинстве браузеров ограничение URL-адреса составляет 2 КБ, а на большинстве серверов — 64 КБ.
У многих людей есть недоразумения по этому поводу, мы должны понять несколько моментов:
1. http не ограничивает длину данных, передаваемых GET и POST
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
2. Правила основаны на браузерах и серверах.
- Кодирование данных
Это также то же самое, что GET соединяется с URL-адресом, поэтому параметры GET могут быть закодированы только в URL-адресе, в то время как POST отличается и может быть закодирован в двоичном формате и т. д.
- представление
Этот аспект в том, что GET лучше, и я обратил на это внимание только когда разбирался, очень много знаний приходит из интернета, так что вы видите, если это не соответствует вашей реальной ситуации, вы можете положить это в комментарии:
GET создает один TCP-пакет, POST — два TCP-пакета.
Для запроса GET заголовок http и данные отправляются на сервер, и сервер возвращает 200.
Но POST отличается: сначала он отправляет http-заголовок, а затем сервер отвечает 100. После отправки данных на сервер сервер отвечает 200.
С точки зрения производительности, одна поездка и две другие поездки, очевидно, быстрее, чем одна поездка.
- Суммировать
Полностью использовать POST явно нецелесообразно, в некоторых случаях, когда данные не являются конфиденциальными, запросы частые, а объем данных меньше ограничения браузера в 2К, разумнее выбрать GET.
Эпилог
По поводу стиля RESTful автор тоже находится в стадии исследования, и сейчас я могу только написать, но почему так написано, как появился этот формат, я не знаю, хахаха, но могу порекомендовать несколько книг для вы, если вам интересно, вы можете взглянуть на «REST на практике», там также опубликован автор стиля RESTДиссертация (английская версия)
Записи блога, на которые есть ссылки в статье
Примечание
Я надеюсь, что это понравится друзьям, которым это нравится, или вы можете подписаться на него, если вы можете передать его блогеру.GitHubА еще лучше, если вы нажмете на звездочку. Давайте работать вместе, 🙏🙏🙏