Веб технологии и кое-что еще

Введение

Чтобы понять как работает Rails, у вас должны быть твердые знания о начинке веба. Некоторые из них вы получили в предыдущих разделах, а здесь у вас будет шанс пойти дальше и создать реальные веб-запросы.

HTTP

Протокол HTTP -- это просто способ структурирования запроса и ответа в "разговоре" между вашим браузером и сервером. В действительности, это даже не "разговор", так как он не имеет какого-то определенного состояния, это больше похоже на "спроси и получи". То, как этот диалог должен происходить, и описывает этот протокол.

Посмотрите этот пост на tutsplus о работе и деталях HTTP. Зайдите отсюда на пару сайтов по вашему выбору (например на http://codenamecrud.ru/).

Обратите внимание на то, что и запрос и ответ имеют заголовки (header), и обычно, тело (body). Заголовки содержат информацию о запросе или ответе (метаданные), к какому сайту идет обращение и каков статус ответа. В теле запроса могут содержаться данные отправленных пользователем форм, cookies или токены аутентификации, в то время как в ответе обычно содержится страница HTML, которую вы запрашиваете.

Другим ключевым моментом является то, что каждый запрос использует один из четырех основных методов (действий) -- GET, POST, PUT и DELETE. Сейчас вы почти всегда видите запросы GET и POST (даже если вы пытаетесь что-то удалить, это подменяется GET запросом), и важно понимать эту разницу между методами.

REST

Термин REST вы будете встречать снова и снова по той причине, что это очень мощная концепция. В основном она означает то, что в сущности есть только 7 вещей, которые можно сделать с ресурсом в Сети, и вы можете это сделать, используя указанные методы. Под ресурсом понимается "нечто" в базе данных, или модель данных. Здесь под ресурсом мы будем подразумевать созданную вами в блоге модель Post:

  1. Получите все посты, с помощью GET (используя "index")
  2. Получите один из постов, также с помощью GET (используя "show")
  3. Используйте GET для получения страницы создания нового поста (здесь будет нужен "new" )
  4. Используйте POST для отправки введенных вами данных формы на сервер, для создания нового поста (здесь нужен "create")
  5. Вызовите с помощью GET пост на редактирование (используя "edit")
  6. С помощью PUT (или PATCH) отправьте измененные данные в посте на сервер (используйте "update")
  7. Удалите какой-нибудь пост, отослав на сервер запрос DELETE ("destroy" соответственно)

Выделенные слова относятся к стандартным методам контроллера Rails!

Почему это важно? Потому, что это дает очень хорошую организацию работы с ресурсами. Это способ моделировать ваши запросы, и должен быть ТОЛЬКО ОДИН способ это сделать (например, не следует использовать GET для отправки отредактированного поста на сервер... это должен делать POST). Если вы надолго задумались над тем, как реализовать эти семь методов в отношении созданного в базе данных ресурса, то вам следует подумать, правильно ли вами реализована структура данных.

Это важно также по той причине, что Rails напрямую следует этим соглашениям, и, собственно, на них и построен. Вы сильно облегчите себе жизнь, следуя этим принципам, - и запрос от браузера в этом случае всегда будет легко обработан системой маршрутизации Rails.

Возможно, поначалу будет проще думать о вещах таким образом, но однажды модель данных окажется сложнее, чем раньше и вы поймете, что возвращение к RESTful-мышлению поможет вам разрешить проблему.

URL

Вероятно, вы думаете, что имеете представление об URL, но какая его часть содержит имя сервера? протокол? параметры? путь?

Посмотрите эту статью от Matt Cutts, где разбирается URL поискового запроса Google.

Опросник:
Рассмотрите этот URL: https://www.google.com/search?q=what+is+a+url

  1. Что относится к пути запроса?
  2. Какая часть относится к параметрам?
  3. Где домен верхнего уровня?
  4. Что относится к протоколу?

Как только вы разберетесь с этими компонентами, вы с легкостью будете использовать библиотеки Ruby для создания своих собственных, а также запросов к ним. Далее, при использовании Rails, вы будете снова и снова возвращаться к таким вещам, как путь запроса и его параметры.

Ответы: 1. /search 2. q=what+is+a+url 3. com 4. https

MVC

Вы постоянно слышали эту аббревиатуру, но точно ли вы знаете, что такое MVC? Эмммм... Хм...

MVC - это общая концепция, а Rails построен на ее основе. При создании нового Rails проекта, вы получаете созданными немалое количество каталогов и файлов. Несмотря на кажущийся хаос внутри вашего каталога app, все они хорошо систематизированы и предназначены для раздедения Модели (M), Представления (V) и Контроллера (C).

Смысл MVC в том, чтобы разбить приложение на отдельные части. Каждая часть получает свой класс Ruby. Для разработчика это хорошо тем, что при необходимости внести изменения в код, заранее известно, какой файл редактировать и где он находится.

Путь запроса через MVC

Как только в ваше приложение приходит запрос от браузера, происходит следующее:

  1. Маршрутизатор определяет, к какому контроллеру следует направить запрос (например, для нашего блога - к контроллеру PostsController).
  2. Контроллер содержит запросы к модели и выполняет их, получая от нее данные (например от модели Post).
  3. Затем этот контроллер передает эти данные в представление (например index.html.erb), которое, по сути, просто шаблон HTML, ожидающий передачи в него этих переменных.
  4. Как только представление получило данные, оно отсылается клиенту, который отправил исходный запрос. Готово!

Более детальный разбор архитектуры MVC посмотрите здесь

Шутливо, эту троицу можно представить так: модель это сообразительный парень в подсобке, контроллер - посредник интеллигентного вида, который со всеми разговаривает, но не делает ничего особенно сложного (в этих случаях он обращается к парню в подсобке), а представление просто красиво выглядит и ждет обновок от контроллера.

Продолжайте изучение, вы увидите их в действии и полюбите работать с ними.

API

Когда ваш компьютер или программируемый вами сервер хочет послать запрос другому сайту, он может использовать его API для прямого доступа к данным, а не кликать на какую-то ссылку в браузере. API - это просто интерфейс. Наш браузер использует прямой путь для получения кучи информации от фейсбука, а сервер использует обходной путь для получения той же информации через API (причем этот путь короче и намного быстрее).

Вы хотите получить данные с Google Maps, чтобы отобразить их на своей странице? Используйте их API согласно документации Google. Почти у каждого большого сайта есть данные, доступные с использованием его API, и вы можете сделать достаточно легко то же самое на своем сайте, используя Rails.

Посмотрите эти пояснения (первую страницу) о том, Что такое API с сайта howstuffworks

Не все API основаны на Веб. Многие используют формат HTTP, но в действительности просто пересылают данные между службами. В частности, именно так связаны компоненты Rails -- они используют HTTP для связи между собой.

Вскоре вы получите возможность создать свой собственный API, и увидите как это просто с Rails. Здесь нет никакой магии -- контроллер просто должен ответить на запрос от других серверов вместо нормального веб-запроса (или вдобавок к нему), а затем вернуть в ответ необходимые данные (и скорее всего это не будет обычным HTML представлением).

Но мы немного забежали вперед... основной смысл в том, что API используется довольно часто, его использование абсолютно безвредно и это просто способ коммуникации между двумя приложениями.

Cookies

Вы наверняка слышали о куки (cookies). Они используются для того, чтобы сайт мог помнить пользователя от запроса к запросу. Помните - каждый HTTP запрос полностью независим от любого другого. То есть, если вы например идете на домашнюю страницу какого-то сайта, а затем на его страницу "О сайте", то сервер считает вас совершенно новым пользователем.

... до тех пор, пока вы не получили от этого сайта cookies (которые у него наверняка есть). Cookies - это небольшой набор данных, которые ваш браузер отсылает при каждом запросе к сайту. С точки зрения веб-сервера, это позволяет идентифицировать вас как того самого пользователя, который выполнил любую из последовательностей предыдущих запросов. Это позволяет хранить состояние (state) вашей сессии.

На сайте allaboutcookies.org прочтите первые три раздела для получения дополнительной информации о cookies.

Также может быть полезна статья на Википедии.

Перейдите на сайт, который вы обычно посещаете, откройте инструменты разработчика и найдите cookies. В Chrome они будут на закладке "Resources", затем "cookies". Внешне они выглядят как пары имя-значение. Также часто присутствует нечто вроде переменной "user_session" или "token", выглядящих как неразборчивая строка символов.

Сессии

Cookies важны по той причине, что они обеспечивают единственную продолжающуюся "сессию" при работе пользователя с сайтом. Имеется в виду, что вам необходимо залогиниться только один раз, а не при каждом запросе (что, бывало, происходило с некорректно функционирующими сайтами в конце 90-х).

Ваш браузер содержит все необходимые cookies, которые были выданы сайтом, и сервер использует их для определения что вы за пользователь, залогинены ли вы, каковы ваши настройки (например у вас по особому настроен интерфейс сайта) и прочих подобных вещей. Именно поэтому, если вы удаляете cookies из истории браузера, все кажется очищенным и сброшенным на настройки по умолчанию.

Некоторая реклама, которая преследует вас от сайта к сайту, тоже использует эту технологию -- в данном случае применяются так называемые "tracking cookies"

Аутентификация

На стороне сервера, работы с cookies и сессиями совсем немного. Как было сказано выше, одним из основных применений является определение личности пользователя, или "аутентификация". Ваша задача - получить присланные браузером cookies, использовать их для поиска пользователя в базе данных, и (если пользователь существует) отобразить настроенную под него страничку.

В теории достаточно просто, хотя некоторые вопросы безопасности усложняют жизнь. Но, к счастью, ребята из Platformatec создали отличный гем "Devise", на который можно переложить все эти заботы. В этом курсе (чуть позже), вы создадите свою собственную систему аутентификации перед тем, как использовать Devise в качестве тяжеловеса.

Авторизация

Авторизация стоит рядом с Аутентификацией... Аутентификация дает определить, КТО этот пользователь, а авторизация может ограничить его в правах, основываясь на его уровнях доступа. Наиболее распространенный случай - просто различие в доступе между случайными (незалогиненными) и теми пользователями, которые прошли аутентификацию. Другой общий случай - это различие между постоянными поьзователями сайта и администраторами, обладающими специальными привилегиями.

На стороне сервера, вы будете использовать методы, ограничивающие доступ к определенным действиям, в зависимости от типа пользователя (или залогинен ли пользователь вообще). Повторимся, Devise поможет вам, предоставив методы-помощники (например проверку залогинен ли пользователь, или кто текущий пользователь)

Заключение

Чуть позже мы разберем эту тему подробнее, но сейчас важно понять, что в контексте аутентификации, в ранее независимые HTTP запросы привносится пара дополнительных уровней. Системы аутентификации позволяют создавать сессии, сохраняющие от запроса к запросу состояние пользователя (например, признак того, что пользователь залогинился), и помогают вам определить, авторизован ли пользователь для выполнения определенных действий.

Дополнительные ресурсы

Этот раздел содержит полезные ссылки на дополнительные материалы. Это не обязательно, так что расценивайте их как нечто полезное, если вы хотите поглубже погрузиться в тему

Поделиться уроком: