Snippet stash

HTTP servers and clients

Обучающие материалы

• RustCamp: HTTP
• Awesome Rust — Веб-программирование
• Are We Web Yet? — Веб-фреймворки
• Are We Web Yet? — HTTP-клиенты
• Are We Web Yet? — Нижний веб-стек

Низкоуровневые библиотеки

• Hyper
• async-h1
• actix-http

Серверные фреймворки

• Axum

  • Axum
  • Tower
  • Tower HTTP

• Warp

  • Warp
  • Warp Filter

• Rocket — Rocket

• Poem — Poem

• Salvo — Salvo

Низкий уровень

В экосистеме Rust существует несколько основных крейтов, обеспечивающих реализацию HTTP общего назначения и обеспечивающих работу всего разнообразия веб-фреймворков и HTTP- клиентов.

Самым выдающимся и зрелым из них, конечно же, является crate hyper (построенный с использованием tokio). Почти все веб-фреймворки экосистемы Rust построены на его основе.

Основными альтернативами являются:

• async-h1, обеспечивающий async-std экосистему HTTP.
• actix-http, питая actix-web экосистему.

Сервер

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

Наиболее примечательными являются:

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

warp - сверхпростая, компонуемая структура веб-сервера для варп-скоростей, построенная на основе концепции «все есть идея Filter».

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

poem — полнофункциональный и простой в использовании веб-фреймворк , ориентированный на предоставление всех возможностей (например, i18n ) «из коробки».

salvo — мощная и простая платформа веб-сервера , использующая реализацию HTTP/3

tide - Для тех, кто предпочитает async-std экосистему, окончательный выбор (и единственный на данный момент)

Почему actix-web

Все веб-фреймворки, описанные выше (hyper, tide), наследуют кражу работы из асинхронной среды выполнения, в которой они выполняются, и поэтому требуют правильной синхронизации (быть Send) от пользовательских обработчиков HTTP- запросов, что может привести к ненужным или нежелательным накладным расходам. Вот почему actix-webcrate был спроектирован и реализован специально с учетом этого соображения (во избежание кражи работы), он построен поверх crate actix-rt (используя модель потока на ядро) и, таким образом, не требует какой-либо синхронизации в своих обработчиках запросов (что позволяет !Send Future). Кроме того, actix-web на тот момент это был первый зрелый и готовый к использованию веб-фреймворк в экосистеме Rust

HTTP-клиенты в Rust

• Reqwest
• Isahc
• Surf
• AWC
• Ureq

reqwest - это крейт, построенный на основе hyper

isahc - в качестве альтернативы, представляет собой независимую от времени выполнения оболочку (с упором на практичность и эргономику) вокруг знаменитой библиотеки cURL

surf - является основным крейтом для экосистемы async-std, который, однако, не ограничивается async-std только этим и может использовать альтернативные бэкэнды: cURL (через isahc) hyper, WASM (через API браузера window.fetch)

awc - Для actix-web экосистемы значимым вариантом был бы awc, который поддерживает соединения WebSocket «из коробки» (в то время как у большинства других HTTP- клиентов этого нет)

ureq - Для простых и тривиальных сценариев, где асинхронная среда выполнения избыточна и/или предпочтительна низкая накладная стоимость, жизнеспособной альтернативой является крейт ureq

RESTful

rustcamp/4_3_api

REST

RPC

Тайлер Шарбоно: В чем разница между RPC и REST?

Поскольку REST — это скорее архитектурное соглашение/стиль, чем строгая спецификация для RPC, а REST-интерфейсы API обычно в общих чертах основаны непосредственно на HTTP- методах , обычно нет необходимости в специальных фреймворках в Rust для реализации REST- функционального API- сервера или запроса тот самый. Подойдет любой HTTP-сервер или HTTP-клиент.

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

REST — соединение между клиентом и сервером без сохранения состояния.

GET /tasks - показать все задачи
POST /tasks - создать задачу
GET /tasks/{id} - показать задачу
PUT /tasks/{id} - обновить задачу
DELETE /tasks/{id} - удалить задачу

---

1. REST vs RESTful

REST — это философия, RESTful — её практическая реализация.

REST расшифровывается как REpresentational State Transfer и представляет собой архитектурный стиль для сетевой связи между приложениями, в котором для взаимодействия используется протокол без сохранения состояния (обычно HTTP)

• REST — это архитектурный стиль, набор принципов для построения веб-сервисов:

  1. Работа с ресурсами через URI.
  2. Использование стандартных HTTP-методов (GET, POST, PUT, DELETE).
  3. Безсостояние (stateless).
  4. Клиент-серверная архитектура.
  5. Возможность кэширования.

• RESTful — это сервис, который следует этим принципам.

  • Если API нарушает эти принципы (например, использует GET для удаления данных), его нельзя назвать RESTful.

2. Примеры

RESTful API

GET /users       → получить всех пользователей
GET /users/1     → получить пользователя с id=1
POST /users      → создать нового пользователя
PUT /users/1     → обновить пользователя с id=1
DELETE /users/1  → удалить пользователя с id=1

• Чёткое соответствие ресурсам и HTTP-методам → RESTful.

«Не RESTful» API

POST /getUser    → получить пользователя
POST /deleteUser → удалить пользователя

• Используется POST для всех действий, URL указывает на действие, а не на ресурс → не RESTful.

---

Разница между RPC (Remote Procedure Call) и REST (Representational State Transfer) лежит в подходе к организации взаимодействия клиента и сервера. Давай разберём пошагово и с примерами.

Концептуальный подход

RPC:

• Клиент вызывает удалённую функцию (процедуру) на сервере, как будто она локальная.
• Основная идея: действие/операция.
• Фокус на методах, а не на ресурсах.

REST:

• Основан на работе с ресурсами (данными), которые имеют URI.
• Основная идея: CRUD через HTTP-методы (GET, POST, PUT, DELETE).
• Фокус на ресурсах и их состояниях, а не на методах.

2. Протокол и транспорт

RPC:

• Часто использует HTTP, но может работать и через TCP, gRPC, WebSocket.
• Может передавать данные в любом формате: JSON, Protobuf, XML.

REST:

• Строго использует HTTP.
• Формат передачи обычно JSON или XML.
• Использует стандартные HTTP-методы (GET, POST, PUT, DELETE).

3. Стиль URL и вызова

RPC пример:

POST /user.create
{
  "name": "Alice",
  "email": "alice@example.com"
}

• URL содержит действие (user.create), а не ресурс.
• Клиент «вызывает функцию» на сервере.

REST пример:

POST /users
{
  "name": "Alice",
  "email": "alice@example.com"
}

• URL отражает ресурс (/users).
• HTTP-метод определяет операцию (POST = создать, GET = получить, PUT = обновить, DELETE = удалить).

4. Преимущества и недостатки

Итого:

• RPC — «вызови функцию на сервере».
• REST — «возьми ресурс или измени его через стандартные HTTP-операции».

GraphQL в Rust

Основные ресурсы

• GraphQL
• Гибкий подход
• Выразительная система типов
• Экосистема инструментов

Учебные материалы

• Fullstack учебное пособие по GraphQL
• Книга Async-graphql
• Juniper Book

Серверные библиотеки

• Juniper
• Async-graphql
• Juniper-from-schema

Клиентские библиотеки

• GraphQL Client (Rust)
• Cynic
• Cynic официальная документация

Что такое GraphQL

GraphQL — это язык запросов для API и среда выполнения для их обработки. Он был разработан Facebook в 2012 году и открыт как проект с открытым исходным кодом в 2015 году.

Основная идея GraphQL — позволить клиентам запрашивать только те данные, которые им действительно нужны, избегая избыточной передачи данных. Он также позволяет выполнять вложенные и сложные запросы, объединяя получение связанных данных в одном вызове.

Преимущества GraphQL

1. Гибкость запросов

• Клиенты могут запрашивать ровно нужные данные, что уменьшает объем передаваемой информации и повышает эффективность сети.
• Возможность составлять вложенные запросы позволяет получать связанные данные за один вызов.

2. Единый эндпоинт

• GraphQL API использует один общий эндпоинт для всех запросов, в отличие от REST, где для разных ресурсов нужны разные URL.

3. Сильная типизация

• Строгая типизация схемы помогает выявлять ошибки на этапе разработки.
• Схема служит наглядной документацией для API.

4. Автодокументация и инструменты

• Инструменты вроде GraphiQL и GraphQL Playground автоматически генерируют документацию и предоставляют интерактивные интерфейсы для выполнения запросов.

5. Эффективное получение данных

• Несколько запросов можно объединять в один, снижая нагрузку на сеть и сервер.

6. Экосистема

• GraphQL поддерживает генерацию кода из схемы или схемы из кода.
• Интерактивные «песочницы» позволяют тестировать API без дополнительной настройки.
• Протокол независим от транспорта: схемы и запросы можно использовать через HTTP или WebSocket, включая потоковую передачу данных.

Вызовы и ограничения GraphQL

1. Сложность кеширования

• В REST API кеширование привязано к URL и обычно просто.
• В GraphQL один эндпоинт для всех запросов, поэтому кеширование требует дополнительных стратегий.

2. Производительность

• Клиенты могут формировать очень сложные запросы, нагружающие сервер.
• Необходимы ограничения глубины и объема возвращаемых данных.

3. Безопасность

• Возможны атаки типа DoS с избыточной вложенностью или большим числом полей.
• Требуются ограничения сложности запросов и контроль аутентификации/авторизации на уровне полей.

4. Изменения в архитектуре

• Переход с REST на GraphQL требует изменения архитектуры API и обучения команды.
• Внедрение новых концепций может замедлить разработку на начальных этапах.

---

GraphQL в Rust

Сервер

• Juniper — обеспечивает больше статических гарантий (код → схема).
• Async-graphql — более многофункциональный, также использует подход код → схема.
• Juniper-from-schema — реализует обратный подход «схема → код», генерируя Rust-код из предоставленной схемы GraphQL.

Клиент

• Для простых запросов можно использовать любой HTTP-клиент.
• Graphql-client — генерирует Rust-код из файлов GraphQL (подход «запрос → код»).
• Cynic — генерирует запросы GraphQL из Rust-кода и проверяет их соответствие схеме (подход «код → запрос»).

Frontend

leptos реактивные пользовательские интерфейсы (UI) для веб-приложений (вместо React)

Leptos — это фреймворк на языке программирования Rust, который предназначен для создания реактивных пользовательских интерфейсов (UI) для веб-приложений. Вот несколько причин, почему Leptos может быть хорошим выбором для разработки веб-приложений:

• Leptos позволяет создавать реактивные UI, где изменения в данных автоматически отражаются в пользовательском интерфейсе. Это упрощает разработку динамических и интерактивных веб-приложений.
• Leptos поддерживает как серверную (с использованием технологии SSR - Server-Side Rendering), так и клиентскую рендеринг (на стороне клиента). Это позволяет разработчикам выбирать подходящий метод в зависимости от потребностей приложения.
• Leptos использует современные возможности веб-разработки, такие как WebAssembly (Wasm), что позволяет выполнять код на Rust непосредственно в браузере с высокой производительностью.