Ответ
Да, я активно работал как с созданием, так и с использованием API. В основном мой опыт связан с RESTful API и gRPC.
1. Создание API:
- RESTful API: Проектировал и реализовывал RESTful-сервисы на Go. Для простых задач использовал стандартную библиотеку
net/http. Для более сложных приложений с маршрутизацией, middleware и валидацией применял популярные фреймворки, такие как Gin или Chi. - gRPC: Разрабатывал высокопроизводительные микросервисы с использованием gRPC. Описывал контракты сервисов с помощью Protocol Buffers (
.proto) и генерировал на их основе код сервера и клиента. - Документация: Для документирования REST API использовал спецификацию OpenAPI (Swagger), что позволяло автоматически генерировать интерактивную документацию и клиентские SDK.
2. Использование (интеграция) API:
Я регулярно интегрировал наши сервисы со сторонними API. Для отправки HTTP-запросов в Go я использую стандартный пакет net/http.
Пример простого GET-запроса:
package main
import (
"fmt"
"io"
"log"
"net/http"
)
func main() {
// Выполняем GET-запрос к API
resp, err := http.Get("https://api.example.com/data")
if err != nil {
log.Fatalf("Ошибка при выполнении запроса: %v", err)
}
// Важно всегда закрывать тело ответа
defer resp.Body.Close()
// Читаем тело ответа
body, err := io.ReadAll(resp.Body)
if err != nil {
log.Fatalf("Ошибка при чтении ответа: %v", err)
}
fmt.Println(string(body))
}Для более сложных сценариев, таких как работа с JSON, установка кастомных заголовков (например, для авторизации) или управление таймаутами, я настраиваю http.Client. Также имею опыт работы с генераторами клиентов, например oapi-codegen, который создает типобезопасный клиент на основе OpenAPI спецификации.
Ответ 18+ 🔞
Ну, слушай, я с этими вашими API, как с родными, блядь, общался. И создавал их, и пользовался, как последний распиздяй. В основном, конечно, классика жанра — RESTful API и этот ваш gRPC, который всех с ума сводит.
1. Создание API:
- RESTful API: Ну, тут всё понятно, проектировал, писал, страдал хуйнёй. Для простенького — родной
net/httpрулит. А когда надо по-взрослому, с маршрутизацией, middleware и прочей валидационной хуетой — брал Gin или Chi. Без них, блядь, как без рук, если честно. - gRPC: А вот это уже для настоящих мужчин, когда надо, чтобы сервисы между собой болтали со скоростью света. Писал контракты на этих ваших Protocol Buffers (
.proto), а потом код сам, сука, генерируется. Красота, ёпта! - Документация: А, да, этот вечный геморрой — объяснять другим, как моим API пользоваться. Спасала спецификация OpenAPI (Swagger), чтобы не переписывать одно и то же, а документация сама, блядь, генерилась. Умные же люди придумали, в рот меня чих-пых.
2. Использование (интеграция) API:
Тут, блядь, я чаще был на стороне потребителя. Вечно какие-то сторонние сервисы надо было прикрутить. В Go, ясное дело, родной net/http в руки и вперёд.
Пример простого GET-запроса: (Код не трогаю, он святой, блядь)
package main
import (
"fmt"
"io"
"log"
"net/http"
)
func main() {
// Выполняем GET-запрос к API
resp, err := http.Get("https://api.example.com/data")
if err != nil {
log.Fatalf("Ошибка при выполнении запроса: %v", err)
}
// Важно всегда закрывать тело ответа
defer resp.Body.Close()
// Читаем тело ответа
body, err := io.ReadAll(resp.Body)
if err != nil {
log.Fatalf("Ошибка при чтении ответа: %v", err)
}
fmt.Println(string(body))
}Ну а если по-взрослому — JSON'ы парсить, заголовки для авторизации лепить, таймауты выставлять, чтоб не ждать ответа до второго пришествия — тут уже http.Client настраиваешь. А ещё бывало, что на основе OpenAPI-спеки тебе, сука, целый типобезопасный клиент генерируют, например, через oapi-codegen. Вообще песня, а не работа, когда не надо руками всё это ебало писать.