WEB & REST API Flashcards
Что такое REST?
REST (Representational State Transfer)- это архитектурный стиль, который используется для создания распределенных приложений в Интернете. Он был предложен в 2000 году Роем Филдингом (Roy Fielding) в его диссертации “Архитектурные стили и дизайн сетевых программных архитектур”.
REST это набор ограничений-правил, описывающий как правильно написать код серверного веб-приложения, чтобы все системы легко обменивались данными и приложение возможно было масштабировать.
Основная идея REST заключается в том, что клиент и сервер обмениваются ресурсами (например, документами, изображениями, видео и т.д.), которые идентифицируются уникальным идентификатором URI (Uniform Resource Identifier). Клиенты могут запрашивать и получать ресурсы с помощью стандартных HTTP-методов (GET, POST, PUT, DELETE и т.д.), а серверы должны предоставлять эти ресурсы в виде данных (например, в формате HTML, XML, JSON и т.д.), которые могут быть легко обработаны и отображены клиентом.
REST также включает в себя несколько архитектурных ограничений, которые позволяют создавать более гибкие и масштабируемые веб-сервисы. Например, гипермедиа-ориентированный интерфейс (HATEOAS) позволяет клиенту получать информацию о доступных действиях на ресурсах через ссылки, возвращаемые сервером. Ограничение без состояния (Stateless) означает, что сервер не должен хранить информацию о состоянии клиента между запросами, что позволяет легко масштабировать приложение на несколько серверов.
REST позволяет создавать более гибкие, расширяемые и легко поддерживаемые приложения в Интернете. Он является стандартом для создания веб-сервисов и API в Интернете.
В контексте REST (Representational State Transfer) эндпоинт (endpoint) - это конечная точка (URL-адрес), которая представляет собой конкретный ресурс или коллекцию ресурсов в веб-сервисе. Эндпоинт - это место, где клиентские приложения могут отправлять запросы на получение или изменение данных, а сервер может отвечать на эти запросы.
REST = Representational State Transfer
1) Архитектурный стиль взаимодействия компонентов распределенного приложения в сети.
2) Согласованный набор ограничений, учитываемых при проектировании распределённой системы.
Что такое REST API?
**REST API **(Application Programming Interface) - это интерфейс программирования приложений, который основан на архитектурном стиле REST (Representational State Transfer). Он позволяет взаимодействовать с удаленными приложениями или сервисами, используя стандартные HTTP-методы, такие как GET, POST, PUT и DELETE.
REST API позволяет передавать данные между клиентом и сервером в формате JSON, XML или других форматах. Он используется для разработки веб-приложений, мобильных приложений, интеграции с другими сервисами и т.д.
REST API должен быть построен с соблюдением всех ограничений и принципов, определенных в стиле архитектуры REST, таких как идентификация ресурсов, использование HTTP-методов, разделение клиента и сервера, кэширование и т.д.
Перечислите требования REST? 6 принципов REST API
Client-Server Отделяя пользовательский интерфейс от хранилища данных, мы улучшаем переносимость пользовательского интерфейса на другие платформы и улучшаем масштабируемость серверных компонент засчёт их упрощения.
REST API следует принципу разделения клиента и сервера. Клиент и сервер могут развиваться независимо друг от друга, без знания о существовании друг друга. Это позволяет изменять реализацию клиента и сервера, не влияя на другую сторону.
Stateless (без состояния). Каждый запрос от клиента к серверу должен содержать в себе всю необходимую информацию и не может полагаться на какое-либо состояние, хранящееся на стороне сервера. Таким образом, информация о текущей сессии должна целиком храниться у клиента.
REST API должен быть без состояния (stateless). Каждый запрос к серверу должен содержать всю необходимую информацию для его обработки. Сервер не должен хранить информацию о состоянии клиента между запросами. Это позволяет масштабировать систему и улучшить ее производительность.
Cacheable (кэшируемость). Это ограничение требует, чтобы для данных в ответе на запрос явно было указано – можно их кэшировать или нет. Если ответ поддерживает кэширование, то клиент имеет право повторно использовать данные в последующих эквивалентных запросов без обращения на сервер.”
REST API должен поддерживать кэширование, чтобы уменьшить количество запросов и улучшить производительность. Клиент может сохранять ответы на запросы, которые часто повторяются, и использовать их вместо отправки новых запросов на сервер.
Uniform interface (единообразие интерфейса). Если применить к системе инженерный принцип общности/единообразия, то архитектура всего приложения станет проще, а взаимодействие станет прозрачнее и понятнее.
Для выполнения этого принципа необходимо придерживаться нескольких архитектурных ограничений. REST накладывает на интерфейс четыре ограничения:
* Определение ресурса (означает, что каждый ресурс должны быть обозначен постоянным идентефикатором)
* Управление ресурсами через представление (означает, что клиент хранит ресурс в виде его представления, и при желании изменения ресурса он отправляет серверу информацию о том, в каком виде он хотел бы видеть этот ресурс; сервер же рассматривает этот как запрос как предложение, и сам решает, что делать ему с хранимым ресурсом)
* Самодостаточные сообщения (каждое сообщение содержит достаточно информации, чтобы понять, как его обрабатывать)
* Гипермедиа (означает, что клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервер) (HATEOAS) – ссылки на другие ресурсы внутри приложения.
**Uniform Interface **(Единый интерфейс)
REST API должен иметь единый интерфейс, который определяет, как клиенты и серверы общаются друг с другом. Это включает в себя определение ресурсов, используемых в приложении, методов, которые могут быть применены к ресурсам, и форматов, которые используются для представления данных.
Layered system (многоуровневая система). Многоуровневость достигается засчёт ограничения поведения компонентов таким образом, что компоненты ““не видят”” другие компоненты, кроме расположенных на ближайших уровнях, с которыми они взаимодействуют.
REST API должен быть построен на слоистой архитектуре, в которой каждый слой выполняет определенную функцию. Это позволяет скрыть детали реализации от клиентов и серверов, и упростить архитектуру приложения.
Code on demand (код по мере необходимости, необятельно). REST позволяет наращивать функциональность клиентского приложения по мере необходимости при помощи скачивания и исполнения кода в виде апплетов или скриптов. Это упрощает клиентские приложения, уменьшая количество заранее написанных возможностей.
REST API может включать в себя код на запрос, который передается от сервера к клиенту при необходимости. Это позволяет расширять возможности клиента, не изменяя приложение на сервере.
Что означает RESTful?
Термин RESTful обычно используется для описания веб-сервисов, которые следуют архитектурным принципам REST. Это означает, что сервисы предоставляют клиентам доступ к ресурсам через единый интерфейс, используя URI и HTTP-методы, такие как GET, POST, PUT и DELETE.
- Клиент-серверная архитектура: взаимодействие между клиентом и сервером должно быть разделено на отдельные слои, которые могут быть изменены независимо друг от друга.
- Без состояния (Stateless): каждый запрос от клиента должен содержать всю необходимую информацию для сервера, чтобы понимать запрос и выполнить его, без необходимости сохранять информацию о предыдущих запросах.
- Кэширование (Caching): ответы сервера должны быть кэшируемы, чтобы повторные запросы клиента на ту же самую информацию могли быть удовлетворены из кэша, что уменьшит нагрузку на сервер.
- Единообразный интерфейс (Uniform Interface): интерфейс между клиентом и сервером должен быть единообразным, чтобы клиент мог легко понимать, как взаимодействовать с сервером.
- Слои (Layered System): клиент не должен знать о дополнительных слоях между ним и сервером, что позволяет менять или добавлять слои без изменения клиентского кода.
- Отсутствие предварительного состояния (Code-On-Demand): сервер может отправлять код клиенту, который может выполнить для выполнения дополнительных функций, например, скрипты на JavaScript.
Сервис написанный с учетом всех правил REST принято называть RESTful
Каковы преимущества REST API?
REST API - это архитектурный стиль, который использует протокол HTTP для создания веб-сервисов. Он имеет несколько преимуществ перед другими подходами к созданию веб-сервисов:
- Универсальность: REST API может использоваться с любыми клиентами, которые могут отправлять HTTP-запросы и обрабатывать HTTP-ответы. Это делает его универсальным и легко масштабируемым.
- Разделение сервера и клиента: REST API позволяет разделять клиентскую и серверную части приложения, что упрощает разработку и обеспечивает более четкую архитектуру.
- Простота и гибкость: REST API использует простые и понятные HTTP-методы для выполнения операций, таких как создание, чтение, обновление и удаление данных. Это делает его гибким и простым в использовании.
- Надежность: REST API использует HTTP-протокол, который является надежным и широко используется в интернете. Это позволяет обеспечивать надежность и целостность данных при передаче по сети.
- Кэширование: REST API поддерживает кэширование, что позволяет уменьшить нагрузку на сервер и ускорить процесс обработки запросов.
- Поддержка форматов данных: REST API поддерживает различные форматы данных, такие как XML и JSON, что обеспечивает более гибкую передачу данных между клиентом и сервером.
- можем связывать между собой разные сервисы, которые используеют разные языки программирование, разные фреймворки и тд, поскольку данные передаются в формате json чаще всего, который не зависит от конкретной технологии от конкретного языка программирования, он универсален для всех языков программирования, и все языки программирования могут с ним работать.
- Также к одному сервису могут обращаться сразу несколько сервисов, то есть написали бэк, а множество фронтов обращаются за данными
Также REST API популярны среди микросервисов.
Обычный подход к работе над приложением - это монолитный подход, когда у нас в одном приложении всё находится, контроллеры, сервисы и тд. Но когда проект расрастается, то им становится сложнее управлять, изменять, дополнять, когда всё в одной куче, поэтому монолитное приложение разбирается на микросервисы, небольшие сервисы, слабо связанные и легко изменяемые приложения, которые выполняет какие-то элементарные функции. Эти с другом с помощью API, то есть обмениваются между собой данные чаще всего в формате json, тем самым могут использовать разные языки программирования С микросервисами можно изменять какой-то конкретный модуль, при этом это изменение не будет отражаться на других модулях, как это было при монолите.
Микросервисы могут быть распределенными, то есть могут работать на множестве серверов, тем самым это
позволяет нам горизонтально масшабироваться, докупая сервера при необходимости, не увеличивать мощность текущего сервера
Каковы недостатки REST API?
- получаемые данные из какого-то сервиса часто бывают избыточными или неполными
- До сих пор нет общего согласования того, что такое REST API. Это по поводу статусов ответа, порой трудно понять когда и какой статус ответа использовать, можем ли мы, например, использовать для изменения пользователя статус 200 или 201
- rest привязан сильно к http протоколу
- Отсутствие формальной спецификации: REST API не имеет формальной спецификации, что может привести к несоответствию между клиентскими и серверными интерфейсами.
- Ограниченность методов: REST API ограничивает набор методов, которые можно использовать для взаимодействия с ресурсами. Это может привести к необходимости использования обходных путей для реализации некоторых функций.
- Сложность понимания для новичков: Из-за отсутствия формальной спецификации и широкого спектра возможных реализаций, REST API может быть сложен для понимания для новичков.
- Большое количество запросов: REST API может потребовать большого количества запросов для получения необходимых данных, что может ухудшить производительность приложения.
- Отсутствие безопасности: REST API не обеспечивает безопасности, так как все данные передаются в открытом виде. Для обеспечения безопасности приходится использовать дополнительные механизмы, такие как SSL и токены авторизации.
Объясните ограничения единого интерфейса
Одним из основных принципов архитектурного стиля REST является ограничение на единый интерфейс, который клиенты могут использовать для взаимодействия с сервером. Единый интерфейс включает в себя четыре ограничения:
- Идентичность ресурсов (Resource identification) - каждый ресурс должен быть идентифицирован уникальным URI (Uniform Resource Identifier).
- Манипуляция над ресурсами через представление (Resource manipulation through representations) - клиенты могут модифицировать ресурсы, отправляя запросы на URI, которые описывают операции над ресурсами (например, GET, POST, PUT, DELETE). При этом клиенты должны отправлять данные в виде представления (representation) ресурса, которое может быть в разных форматах, таких как JSON, XML или HTML.
- Исчерпывающие, понятные человеку сообщения(Self-descriptive messages) - запросы и ответы должны содержать достаточно информации для понимания, как обрабатывать сообщения, без дополнительной информации от клиента или сервера. Для этого используются заголовки HTTP, которые описывают формат сообщений, тип содержимого и другую мета-информацию.
- Гипермедиа (Hypermedia) как движок для состояния приложения (HATEOAS) - сервер должен включать в ответы ссылки на связанные ресурсы, которые могут быть запрошены клиентом. Это позволяет клиенту определить, какие действия можно совершить над ресурсами и какие ресурсы могут быть получены дополнительно. Такой подход упрощает изменение API и добавление новых функций без изменения клиентского кода.
1) идентичность ресурсов;
2) 2) манипуляция над ресурсами через представление;
3) 3) исчерпывающие, понятные человеку сообщения;
4) 4) гипермедиа (hypermedia) как движок для состояния приложения (HATEOAS) – ссылки на другие ресурсы внутри приложения.
Ограничение на единый интерфейс упрощает клиент-серверное взаимодействие, уменьшает зависимости между клиентом и сервером и повышает гибкость системы. Оно также упрощает масштабирование системы, поскольку все клиенты используют один и тот же интерфейс для взаимодействия с сервером.
Гипермедиа (HATEOAS)
HATEOAS (Hypermedia as the Engine of Application State) - это принцип архитектуры REST, который определяет способ представления ресурсов и связей между ними в веб-сервисе.
Простыми словами, HATEOAS означает, что каждый ресурс в веб-сервисе должен содержать не только саму информацию, но и ссылки на другие связанные ресурсы, а также информацию о том, как эти ссылки могут быть использованы для выполнения различных операций над ресурсами.
Например, если веб-сервис представляет собой интернет-магазин, ресурс “корзина” может содержать не только информацию о товарах, но и ссылки на страницы для добавления товаров в корзину, удаления товаров и оформления заказа. Это позволяет клиентскому приложению использовать эти ссылки для выполнения соответствующих операций, не требуя предварительного знания конкретных URL-адресов.
Таким образом, принцип HATEOAS обеспечивает более гибкую и универсальную работу с веб-сервисом, упрощает его использование и облегчает его сопровождение.
Вот пример контроллера REST API на Java с использованием фреймворка Spring Boot и Spring HATEOAS, который возвращает JSON-ответ с гиперссылками на другие ресурсы:
~~~
@RestController
public class ProductController {
@GetMapping("/products/{productId}")
public Product getProduct(@PathVariable long productId) {
// Здесь мы получаем объект продукта по его идентификатору из базы данных или другого источника данных
Product product = getProductFromDatabase(productId);
// Создаем гиперссылки на другие ресурсы
Link selfLink = WebMvcLinkBuilder.linkTo(ProductController.class).slash("/products/" + productId).withSelfRel();
Link addToCartLink = WebMvcLinkBuilder.linkTo(CartController.class).slash("/cart/add/" + productId).withRel("add_to_cart");
// Добавляем гиперссылки к объекту продукта
product.add(selfLink, addToCartLink);
return product;
}
private Product getProductFromDatabase(long productId) {
// Здесь мы имитируем получение объекта продукта из базы данных или другого источника данных
return new Product(productId, "Example Product", "This is an example product.", 9.99);
}
}
~~~
В этом примере контроллер ProductController имеет метод getProduct, который получает объект продукта по его идентификатору и добавляет к нему гиперссылки на другие ресурсы. Метод linkTo из класса WebMvcLinkBuilder используется для создания гиперссылок на методы контроллера ProductController и CartController. Метод add из класса org.springframework.hateoas.RepresentationModel используется для добавления гиперссылок к объекту продукта.
Вот пример JSON-ответа, который возвращает этот контроллер:
{
"productId": 1234,
"name": "Example Product",
"description": "This is an example product.",
"price": 9.99,
"_links": {
"self": {
"href": "http://localhost:8080/products/1234"
},
"add_to_cart": {
"href": "http://localhost:8080/cart/add/1234"
}
}
}
Обратите внимание на свойство _links, которое содержит гиперссылки на другие ресурсы. Каждая гиперссылка представлена объектом с именем отношения (self, add_to_cart) и свойством href, которое содержит URL-адрес ресурса.
JSON
JSON (JavaScript Object Notation) - это легкий формат обмена данными, основанный на синтаксисе объектов JavaScript. Он широко используется в веб-разработке для передачи данных между клиентом и сервером.
JSON представляет данные в виде пар “имя/значение” и структурирован в виде объектов и массивов. Он может содержать строки, числа, логические значения, массивы и объекты, а также нулевое значение.
JSON является удобным форматом для обмена данными, так как он прост в использовании и понимании, а также поддерживается многими языками программирования и платформами. Он может использоваться для передачи данных в различных форматах, включая AJAX-запросы, RESTful API и др.
Как в java происходит конвертация json в java код.
Для конвертации JSON в объекты Java в языке программирования Java часто используется библиотека Jackson. Она позволяет сериализовать (конвертировать в JSON) и десериализовать (конвертировать из JSON в объекты Java) данные.
Например, предположим, у нас есть JSON-строка, представляющая объект Person:
~~~
{
“firstName”: “John”,
“lastName”: “Doe”,
“age”: 30
}
~~~
Чтобы преобразовать эту строку в объект Person, необходимо выполнить следующий код:
import com.fasterxml.jackson.databind.ObjectMapper;
public class Main {
public static void main(String[] args) throws Exception {
String json = "{\"firstName\":\"John\",\"lastName\":\"Doe\",\"age\":30}";
ObjectMapper objectMapper = new ObjectMapper();
Person person = objectMapper.readValue(json, Person.class);
System.out.println(person);
}
}
В данном примере мы использовали метод readValue() из библиотеки Jackson, который принимает строку в формате JSON и класс Java, в который необходимо конвертировать JSON. В результате выполнения метода мы получаем объект класса Person, который мы можем использовать в своей программе.
Что такое CRUD?
CRUD - это акроним, который означает Create (Создание), Read (Чтение), Update (Обновление) и Delete (Удаление). CRUD - это основные операции, которые могут быть выполнены над любой постоянной системой хранения данных, такой как база данных, файловая система и т.д. Они представляют собой стандартный набор операций, которые позволяют создавать, читать, изменять и удалять данные.
Примеры использования CRUD:
- Создание: создание нового пользователя в базе данных;
- Чтение: чтение информации о продукте из базы данных;
- Обновление: изменение цены товара в базе данных;
- Удаление: удаление пользователя из базы данных.
CRUD используется во многих приложениях и системах, таких как веб-приложения, мобильные приложения, системы управления контентом и т.д. Он облегчает работу с данными и позволяет эффективно управлять ими.
Что такое SOAP?
SOAP (Simple Object Access Protocol) - это протокол обмена структурированными сообщениями в формате XML между компьютерными системами. SOAP используется для обмена данными между приложениями, работающими на разных платформах и написанными на разных языках программирования. SOAP предоставляет механизмы для вызова удаленных процедур и передачи сообщений между различными системами.
SOAP-сообщение обычно состоит из трех частей:
Сообщение SOAP выглядит так:
Envelope — корневой элемент, который определяет сообщение и пространство имен, использованное в документе.
Header — содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации.
Body — содержит сообщение, которым обмениваются приложения.
Fault — необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений.
В чем разница между SOAP и REST?
На самом деле, сравнивать их немного похоже на сравнение яблок с апельсинами, поскольку SOAP — это формат протокола, основанный на XML, тогда как REST — это архитектурный подход.
Основные различия между ними:
- Архитектура: SOAP является протоколом, основанным на XML, который работает на основе структурированных сообщений, а REST основан на архитектуре клиент-сервер и работает с ресурсами через универсальный набор операций HTTP.
- Формат данных: SOAP использует XML для форматирования данных, а REST может использовать различные форматы, такие как JSON, XML или даже текст.
- Модель безопасности: SOAP имеет свой собственный набор стандартов для безопасности, таких как WS-Security, в то время как в REST безопасность обычно достигается с помощью HTTPS и базовой аутентификации.
- Производительность: REST обычно более производительный, так как использует более простой формат данных и не имеет накладных расходов, связанных с обработкой XML.
- Поддержка: SOAP имеет широкую поддержку со стороны инструментов и языков программирования, в то время как REST считается более простым и имеет менее жесткие требования к клиентам.
- Кеширование: REST легко кешируется на стороне клиента, в то время как SOAP трудно кешируется.
Расскажите о методах HTTP-запросов, поддерживаемых REST, и о том, когда они используются.
REST использует методы HTTP-запросов для взаимодействия с ресурсами. Основными методами являются:
GET: используется для получения информации о ресурсе. GET-запрос может содержать параметры запроса, передаваемые в URL-адресе, и сервер должен вернуть запрошенную информацию в теле ответа.
POST: используется для создания нового ресурса. POST-запрос содержит данные, которые должны быть сохранены на сервере, и сервер должен вернуть ответ, указывающий, что ресурс был успешно создан.
PUT: используется для обновления существующего ресурса. PUT-запрос содержит данные, которые должны быть сохранены на сервере, и сервер должен вернуть ответ, указывающий, что ресурс был успешно обновлен.
DELETE: используется для удаления ресурса. DELETE-запрос должен содержать идентификатор ресурса, который должен быть удален, и сервер должен вернуть ответ, указывающий, что ресурс был успешно удален.
PATCH: используется для частичного обновления ресурса. PATCH-запрос содержит только ту часть данных, которая должна быть обновлена, а не все данные ресурса.
OPTIONS: используется для получения информации о доступных методах HTTP-запросов для ресурса.
Различие между методами GET и POST
Метод GET используется для запроса ресурса у сервера. Он передает параметры запроса (например, запрос на получение конкретного ресурса) в URL-адресе, который затем отправляется на сервер. GET-запросы могут кэшироваться браузером и прокси-серверами, что может ускорить процесс получения данных. GET-запросы не могут использоваться для изменения данных на сервере.
GET передает данные в URL в виде пар “имя-значение”, данные видны всем в адресной строке браузера. Длина запроса не более 2048 символов. Следует использовать для получения данных от сервера и не желательно в запросах, предполагающих внесений изменений в ресурс.
GET ограничен максимальной длинной(ограничение устанавливается на сервере).
GET не поддерживает передачу бинарных данных.
GET используется для получения информации
Метод POST, в отличие от метода GET, используется для отправки данных на сервер, обычно с целью создания или обновления ресурсов. POST-запросы передают данные в теле запроса, а не в URL-адресе. POST-запросы не кэшируются, что может замедлить процесс получения данных. Однако, POST-запросы могут использоваться для изменения данных на сервере.
POST используется для добавления данных
POST передает данные в теле запроса. Данные можно увидеть только с помощью инструментов разработчика, расширений браузера. Следует использовать в случаях, когда нужно вносить изменение в ресурс. HTTP метод POST поддерживает тип кодирования данных multipart/form-data, что позволяет передавать файлы.
Передача данных методом POST более безопасна, чем методом GET, так как секретные данные (например пароль) не отображаются напрямую в web-клиенте пользователя, в отличии от URL, который виден почти всегда. Иногда это преимущество превращается в недостаток - вы не сможете послать данные за кого-то другого.
