Готовлюсь к сдаче ИПР

REST

С REST-запросами всё относительно просто.

Есть протокол HTTP, который позволяет передать на сервер запрос и получить ответ.

У запроса есть заголовки и тело. Заголовки представляют из себя пары типа ключ:значение. Тело — не обязательно. В заголовках, первой строкой идёт МЕТОД (как правило GET, POST, PUT или DELETE), URI (ресурс к которому идёт обращение), HTTP/версия.

REST переводится примерно как репрезентативная (как-бы человекопонятная) передача состояния.

Дело в том, что изначально тип запроса задумывался как:

GET — получить ресурс,
POST — создать ресурс,
PUT — изменить ресурс,
DELETE — удалить ресурс.

Сложность в том, что сервер:
А — не обязан адекватно реагировать на эти запросы. Т.е. на запрос типа DELETE, в зависимости от настроек, он может тупо отдавать ресурс.
Б — вообще не обязан поддерживать никакие типы запросов, кроме GET и POST.

По сути, REST — это группа принципов взаимодействия клиента и сервера, где запросы представляют собой понятия команда-ресурс.

Команда, это тип запроса (один из четырёх, что представлен выше).

Ресурс — это, тот же URL, но собранный так, чтобы по нему было понятно куда происходит обращение. Например, запрос GET https://www.alexcube.ru/blog/2022/02/bez-idej/ требует выдать страницу, находящуюся на домене www.alexcube.ru в рубрике blog, созданную в феврале 2022 года, с заголовком bez-idej.

Кроме того, одним из заголовков запроса будет указание формата возвращаемых данных. Например Accept: application/json укажет, что данные должны вернуться в формате JSON.

REST, это как-бы стандартизированный порядок взаимодействия между клиентом и сервером.

Благодаря этому, можно менять в клиентской и серверной части что угодно, но взаимодействовать всё будет как раньше, поскольку команды останутся прежними.

Без REST я могу передать запрос POST /blog/, в котором (в заголовках) будет зашита команда на удаление конкретной страницы в блоге. И моё веб-приложение её поймёт, если всё настроить как надо. Но глядя на строку запроса не увижу и не пойму что она должна сделать.

С REST, запрос станет выглядеть например так: DELETE /blog/page123. Тут сразу видно, что мы отправляем запрос на удаление страницы 123 в рубрике Блог. Но главное, мне не нужно держать в голове что я должен передавать серверу в заголовках запроса, чтобы он совершил нужное действие.

Из всего этого следует 7 принципов:

1. Отделение клиента от сервера (Client-Server). Т.е. сервер отдельно, клиент — отдельно. Клиент не хранит данные сервера, а сервер никак не связан с интерфейсом клиента.
2. Отсутствие записи состояния клиента (Stateless). Сервер не хранит состояния клиента. Ему не важно какие команды происходили до этого. Он тупо отвечает на текущий запрос. А запрос должен содержать все необходимые данные для формирования ответа и идентификации клиента. Никаких дозапросов. Один запрос — один ответ.
3. Кэшируемость (Casheable). Каждый ответ должен помечаться кешировать его или нет. Например, если ответ — содержимое страницы, то нет смысла всякий раз тревожить сервер. Полученные данные могут остаться в буфере у клиента и вызываться из него. Зато, если ответ, например, текущая температура реактора, то тут при каждом запросе важно получить именно текущую температуру, а не температуру недельной давности.
4. Единство интерфейса (Uniform Interface). Сервер и клиент должны понимать команды, с помощью которых они общаются. Команды должны быть едиными. Нельзя в одном разделе создавать документ командой POST, а в другом командой PUT. Иначе будут проблемы с масштабированием и ошибки.
5. Многоуровневость системы (Layered System). Т.е. систему можно разделить на компоненты. К примеру, я обращаюсь к кассе, а касса обращается к банку. При этом, я не могу обратиться к банку, а банк — ко мне. Т.о. компонент работает только с теми слоями, которые находятся «рядом» с ним.
6. Предоставление кода по запросу (Code on Demand). По запросу клиент сервер может предоставить код, который выполнится на стороне клиента.
7. Начало от нуля (Starting with the Null Style). Приложение может обратиться к корневому разделу сайта, а сервер должен предоставить всё необходимое, чтобы клиент мог начать работу с этой «нулевой» отметки.

Тут вроде всё.

JSON

С JSON тоже не сложно.

По сути, это обычный текст. Практически то же самое, что html или xml. Но есть и разница. JSON задумывался для передачи голых структурированных данных. Т.е. там не должно быть вообще ничего лишнего.

Чаще всего используется для передачи данных между клиентом и сервером. Главный плюс в том, что запрос получается довольно лёгким в плане трафика или хранения.

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

Что такое JSON-объект? Это текст в фигурных скобках, где в двойных кавычках и через запятую перечислены пары «ключ»:»значение». Ключ должен быть уникальным.

Например: {«familnya»:»Иванов»,»imya»:»Иван»}. Вот такой простенький объект.

Ключ всегда в кавычках. Значение в кавычках, только если его тип — строка.

Массив в JSON пишется точно так-же как и объект, только скобки квадратные.

Например [1, «Иванов», {«familiya»:»Петров», «age»:21}, [1,2,5,7,3], true]. Здесь массив имеет пять ячеек. Первая — число, вторая — строка, третья — объект, четвёртая — массив, пятая — булево значение.

Чем плох массив из примера? Лично мне не нравится то, что он не ассоциативный. Давай его слегка переделаем, добавив ключи.

[
   "number":1, 
   "f":"Иванов", 
   "data":{"familiya":"Петров", "age":21}, 
   "somearray"[1,2,5,7,3], 
   "norm":true
]

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

И, важный момент, нельзя путаться с запятыми. Если в PHP не будет ошибкой задать массив вот так [1,2,3,], то JSON, с этой лишней запятой после тройки, просто не распарсится и мы получим ошибку.

Семь навыков успешных людей

Вот теперь, будем считать, что у меня снова дошли руки до этой книги. Перечислю эти 7 навыков здесь, чтобы не искать по одному.

1. Будьте проактивны.
2. Начиная, представляйте конечную цель.
3. Сначала делайте то, что нужно делать сначала. Порядок приоритетности:
   • Важное и срочное
   • Важное и несрочное
   • Неважное и срочное
   • Неважное и несрочное
4. Думайте в духе «выиграл-выиграл» («win-win»).
5. Сначала старайтесь услышать, а потом быть услышанным.
6. Достигайте синергии (стремитесь к творческому взаимовыгодному взаимодействию).
7. Затачивайте пилу (постоянно совершенствуйтесь).

Рабочий день закончился. Нужно закрыть задачи и немного передохнуть. Пожалуй, послушаю музыку.

А затем, читать и запоминать.