Пользовательские данные - это наиболее ценные ресурс вашего веб-приложения. Такие большие компании как Amazon, Google, Facebook используют пользовательские данные для того, чтобы получать прибыль. Например, они используют очень часто их для того, чтобы быть более точно таргетировать рекламу. Но каким образом мы можем получить пользовательские данные? Для того чтобы ответить на этот вопрос, нужно понять, для чего мы хотим получить, и какие пользовательские данные. Например, является ли ключевое слово поиска пользовательскими данными? Да, является. Вы получаете их от пользователя, соответственно, они являются пользовательскими данными. Является фамилия, имя пользователя пользовательскими данными? Да, тоже являются. Вы их храните в базе, вы ими часто будете пользоваться, это очень важная информация, которую вы, как правило, будете хранить. Итак, каким образом мы хотим получить, допустим, ключевое слово поиска? Обычно для таких целей используется Query string. Query string - это неиерархическая часть url. Url, как вы должны помнить из предыдущих частей курса, - это uniform resource locator. Итак, query string - это набор параметров в виде ключ-значение. Вы можете передавать в query string аскисовместимые символы, либо кодированный юникод. Query string очень часто применяется именно для выборки неких объектов. Например, на том же самом сайте Amazon, который мы видим слева, есть query string, который влияет на результат выдачи, на поисковый результат выдачи. Второй популярный способ - это передача пользовательских данных через request body. Обычно через request body передаются более структурированные данные, это могут быть различные большие документы или же это могут быть файлы, или же это может быть бинарная информация. Тем не менее, в request body вы можете передавать как форм дату, которая очень похожа на query string. Также вы можете передавать multipart forma, то есть вы можете передавать файлы одновременно с текстом, одновременно с JSON-файлами и так далее. Вы можете выбрать любой другой источник данных, которые есть в main type стандарта HTP. В частности, это может быть JSON, это может быть message pack, это может быть XML, - все, что необходимо вашему приложению. Очень важно помнить о методах запросов http. Как вы должны знать из предыдущих видео, в стандарте http есть несколько методов: это get, post, delete, put и так далее. Дальнейшие служебные методы мы в рамках курса не рассматриваем. Итак, когда мы говорим о методах, мы должны помнить о свойстве их демпотентности. Этот термин пришел из математики. Он означает примерно следующее: если метод неидемпотентен, то последующие его вызовы влияют на состояние систем. Очень сложная формулировка, давайте разберем на примере. Например, метод get для получения информации. Допустим, у нас есть точка, где мы выдаем данные пользователя, и мы запрашиваем эту точку. Нам вернутся данные пользователей. Если мы запросим эту точку еще раз, то вернутся те же самые данные пользователя, при условии что они не были изменены на сервере. То есть каждый последующий вызов этого метода приводит ровно к тем же самым результатам, система не изменяется. С другой стороны, есть метод post, которым обычно создаются новые ресурсы, объекта и так далее. Если мы вызовем метод post один раз, то произойдёт создание объекта. Если мы вызовем его ещё один раз, произойдёт ещё создание объекта. Таким образом, каждый последующий вызов будет создавать новый объект. Таким образом мы можем говорить, что метод post неидемпотентен, а метод get идемпотентен. Методы delete. Метод delete является так же идемпотентным, метод put также является идемпотентным. При каждом последующем запросе на метод put объект будет заменяться другим объектом. Если мы повторим это несколько раз, то эффект будет тот же самым. Почему мы вспоминаем про методы? Потому что веб-серверы, которые работают с запросами от пользователей, очень часто по дефолту настроены на то, чтобы кешировать некоторые виды запросов, наиболее часто это запросы вида get, потому что этот запрос гарантировано идемпотентен, и его очень удобно кешировать, то есть не выдавать каждый раз одну и ту же информацию о пользователе, таким образом нагружая базу данных веб-приложения, а сохранить где-то уже сформированный документ и выдавать каждый раз его, это быстрее и эффективнее. Также стоит вспомнить про методологию REST - representational State Transfer.. Это набор правил, благодаря которому вы можете построить очень удобный и легко обслуживаемый API. Более подробно вы можете изучить положения этой методологии по ссылке внизу. Мы остановимся только на основных ключевых понятиях. Каждый ресурс вашего веб-приложения является либо конечным ресурсом, либо коллекцией. Например,.api/версия api/users - это коллекция объектов, там храним пользователей и можем создавать новых. Вот пример запроса на создание пользователя. Как видите, он делается в коллекцию, нам возвращается репрезентация созданного пользователя, и мы уже можем с ней работать. Либо мы можем запросить конкретный объект, который идентифицируется каким-то конкретным идентификатором. Вот пример запроса на получение информации о конкретном объекте. Как видим, мы используем идентификатор, и все достаточно прозрачно. Почему стоит строить свое API, на мой взгляд, именно так? Потому что разработчик, который будет работать с вашими API, а с той стороны обычно бывают не только пользователи, а еще и другие разработчики, им удобнее будет понимать именно такую схему, потому что она достаточно распространена. Помимо REST есть другие методологии, например, SOUP, но, к сожалению, в данном курсе мы их рассматривать не будем, мы остановимся более подробно именно на REST, и все наши дальнейшие примеры и приложениях будут созданы с использованием этой методологии. Итак, мы пробежались достаточно быстро по основным понятиям получения данных от пользователей и не только. Чтобы приступить к практике, мы попробуем с вами создать веб-страницу с формой и отправить данные, и посмотрим, что у нас получится.
