Пам’ятка по Rails, CodenameCRUD - безкоштовне навчання веб-розробці

Щоб зрозуміти, як працює Rails, у вас повинні бути тверді знання про начинку вебу. Деякі з них ви отримали в попередніх розділах, а тут ви матимете шанс піти далі і створити реальні веб-запити.

Протокол HTTP - це просто спосіб структурування запиту та відповіді у "розмові" між вашим браузером і сервером. Насправді, це навіть не "розмова", оскільки вона не має якогось певного стану, це більше схоже на "запитай і отримай". Те, як цей діалог має відбуватися, описує цей протокол.

Перегляньте цей пост на tutsplus про роботу і деталі HTTP. Зайдіть звідси на пару сайтів на ваш вибір (наприклад на http://codenamecrud.ru/).

І запит і відповідь мають заголовки (header), і зазвичай, тіло (body). Заголовки містять інформацію про запит або відповідь (метадані), до якого сайту йде звернення та статус відповіді. У тілі запиту можуть бути дані відправлених користувачем форм, cookies або токени автентифікації, у той час як у відповіді зазвичай міститься сторінка HTML, яку ви запитуєте.

Іншим ключовим моментом і те, кожен запит використовує одне із чотирьох основних методів (дій) -- GET, POST, PUT і DELETE. Зараз ви майже завжди бачите запити GET та POST (навіть якщо ви намагаєтеся щось видалити, це підміняється GET запитом), і важливо розуміти цю різницю між методами.

Термін 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, але яка частина містить ім'я сервера? протокол? параметри? шлях?

Перегляньте цю статтю від Matt Cutts, де розбирається URL пошукового запиту Google.

  1. Що стосується шляху запиту?
  2. Яка частина стосується параметрів?
  3. Де домен верхнього рівня?
  4. Що стосується протоколу?

Як тільки ви розберетеся з цими компонентами, ви з легкістю використовуватимете бібліотеки Ruby для створення своїх власних, а також запитів до них. Далі, при використанні Rails, ви знову і знову повертатиметеся до таких речей, як шлях запиту та його параметри.

Відповіді: 1. /search 2. q=what+is+a+url 3. com 4. https

Ви постійно чули цю абревіатуру, але чи точно ви знаєте, що таке MVC? Емммм. Хм.

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

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

Шлях запиту через MVC

Як тільки у вашу програму приходить запит від браузера, відбувається наступне:

Більш детальний аналіз архітектури MVC подивіться тут

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

Продовжуйте вивчення, ви побачите їх у дії та полюбите працювати з ними.

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

Ви хочете отримати дані з Google Maps, щоб відобразити їх на вашій сторінці? Використовуйте їх API згідно з документацією Google. Майже кожен великий сайт має дані, доступні з використанням його API, і ви можете зробити досить легко те ж саме на своєму сайті, використовуючи Rails.

Перегляньте ці пояснення (першу сторінку) про те, що таке API з сайту howstuffworks

Не всі API базуються на Інтернеті. Багато хто використовують формат HTTP, але насправді просто пересилають дані між службами. Зокрема, саме так пов'язані компоненти Rails - вони використовують HTTP для зв'язку між собою.

Незабаром ви отримаєте можливість створити свій власний API, і побачите, як це просто з Rails. Тут немає ніякої магії - контролер просто повинен відповісти на запит від інших серверів замість нормального веб-запиту (або на додаток до нього), а потім повернути у відповідь необхідні дані (і швидше за все це не буде звичайним HTML уявленням).

Але ми трохи забігли вперед. основний сенс у тому, що API використовується досить часто, його використання є абсолютно нешкідливим і це просто спосіб комунікації між двома додатками.

. доти,поки ви не отримали від цього сайту cookies (які, напевно, є). Cookies – це невеликий набір даних, які ваш браузер надсилає при кожному запиті до сайту. З точки зору веб-сервера, це дозволяє ідентифікувати вас як того користувача, який виконав будь-яку з послідовностей попередніх запитів. Це дозволяє зберігати стан вашої сесії.

На сайті allaboutcookies.org прочитайте перші три розділи для отримання додаткової інформації про cookies.

Перейдіть на сайт, який ви зазвичай відвідуєте, відкрийте інструменти розробника та знайдіть cookies. У Chrome вони будуть на закладці "Resources", потім "cookies". Зовні вони виглядають як пари назва-значення. Також часто є щось на зразок змінної "user_session" або "token", що виглядають як нерозбірливий рядок символів.

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

Ваш браузер містить усі необхідні cookies, які були видані сайтом, і сервер використовує їх для визначення, що ви за користувач, чи залогінені ви, які ваші налаштування (наприклад у вас по особливому настроєний інтерфейс сайту) та інших подібних речей. Саме тому, якщо ви видаляєте cookies з історії браузера, все здається очищеним і скинутим за замовчуванням.

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

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

Теоретично досить просто, хоча деякі питання безпеки ускладнюють життя. Але, на щастя, хлопці з Platformatec створили чудовий гем "Devise", на який можна перекласти всі ці турботи. У цьому курсі (трохи пізніше), ви створите свою власну систему автентифікації перед тим, як використовувати Devise як важкоатлет.

Авторизація

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

Висновок

Додаткові ресурси

Цей розділ містить корисні посилання на додаткові матеріали. Це не обов'язково, так що розцінюйте їх як щось корисне, якщо ви хочете глибше поринути у тему