Основы разработки REST и RESTful API

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

В этом посте я хотел бы объяснить методы разработки RESTful с высоты птичьего полета. Я хочу заняться какие а не как. Хотя я коснусь обеих областей, этот пост предназначен для тех, кто занимается веб-разработкой, но просто не может понять концепцию API REST..

REST для веб-разработчиков

REST акроним расшифровывается как Изобразительное State Transfer. Это может показаться несколько запутанным, а запись в вики делает ее еще более запутанной. Но можно упростить терминологию.

ОТДЫХ - это просто серия руководящие принципы и архитектурные стили, используемые для передачи данных. Он обычно применяется к веб-приложениям, но может также передавать данные в программное обеспечение.

Аббревиатура API расшифровывается как интерфейс прикладного программирования, который является методом соединение с другими библиотеками или приложениями. У Windows есть несколько API, а у Twitter также есть веб-API, хотя они выполняют разные задачи с разными целями..

Объединяя все это вместе, RESTful API - это API, которые следуют архитектуре REST.

Что такое архитектура REST??

Здесь трудно сложить детали. Однако есть некоторые архитектурные константы, такие как:

• консистенция по всему API
• Существование без гражданства, т.е. нет серверных сессий
• Использование HTTP коды состояния где уместно
• Использование Конечные точки URL с логической иерархией
• Управление версиями в URL а не в заголовках HTTP

Не существует каких-либо слишком специфических рекомендаций, таких как спецификация W3C HTML5, которые могли бы привести к путанице, и миазму неопределенности в отношении терминологии REST..

Также приведенный выше список не следует считать жесткими правилами, хотя они верны для большинства современных API RESTful.

ОТДЫХ легкая методология что делает его идеальным для данных HTTP. Вот почему REST стал настолько популярным в сети, и поэтому он широко считается лучшим выбором для разработки API..

Как говорит Винай Сахни, “API - это интерфейс разработчика.” Все должно быть простым в использовании и обеспечивать удобство работы. RESTful API стремятся сделать именно это.

Ключевые выводы для API RESTful

Эти советы в контексте API строго для веб-приложений. Это означает, что HTTP это требование, и это часто означает, что данные API размещены на внешнем сервере. Давайте рассмотрим, как работают API RESTful на стороне пользователя API.

Пользователь API - это веб-разработчик, который может создать сценарий, который подключается к внешнему серверу API, а затем необходимые данные передаются по HTTP. Затем разработчик может отобразить данные на своем веб-сайте. без личного доступа к внешнему серверу (например, получение данных из Twitter).

Вообще говоря, есть четыре команды использовал к получить доступ к RESTful API:

1. ПОЛУЧИТЬ для извлечения объекта
2. СООБЩЕНИЕ для создания нового объекта
3. ПОЛОЖИЛ для изменения или замены объекта
4. УДАЛЯТЬ для удаления объекта

Каждый из этих методов должен быть прошло с вызовом API сказать серверу, что делать.

Подавляющее большинство веб-API только разрешить ПОЛУЧИТЬ Запросы вытащить данные с внешнего сервера. Аутентификация является необязательной, но, безусловно, хорошей идеей, если разрешены потенциально опасные команды, такие как ПОЛОЖИЛ или же УДАЛЯТЬ.

Однако не многие RESTful API даже заходят так далеко. Рассмотрим Pokéapi, которая является бесплатной базой данных API Покемонов. Он открыт для общественности с приличным ограничением скорости (ограничивая пользователей определенным количеством запросов API в течение определенного периода времени), но позволяет только ПОЛУЧИТЬ метод доступа к ресурсам. Это может быть условно названо API только для потребления.

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

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

Доступ к ресурсам API

Публичные API обычно доступны с прямых адресов сайтов. Это означает структура URL важна, и должен использоваться только для запросов API.

Некоторые URL-адреса могут включать префикс каталога, например / V2 / для обновленной версии 2 предыдущего API. Это характерно для разработчиков, которые не хотят обесценивать свой API 1.x, но все же хотят предложить новейшую структуру.

Мне очень понравилось это пост покрытие основные структуры URL и примеры из других сервисов.

Обратите внимание, что конечная точка возвращаемые данные изменятся значительно на основе HTTP метод. Например, ПОЛУЧИТЬ извлекает контент, в то время как СООБЩЕНИЕ создает новый контент. Запрос может указывать на одну и ту же конечную точку, но результат может сильно отличаться.

Просмотр примеров в Интернете может помочь вам лучше понять концепции. Мы уже видели Pokeapi, но вот некоторые другие примеры реальных API читать:

• Reddit API
• GitHub API
• Flickr API
• Pinterest API

Создание собственного API

Процесс создания вашего собственного API не следует воспринимать легкомысленно, но он также не так сложен, как вы думаете. Это займет понимание шаблонов проектирования API и лучших практик построить что-то реальное.

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

Но давайте посмотрим на некоторые основные принципы архитектуры API.

Построить конечные точки

Одним из аспектов разработки API является конечные точки здания. когда создание ресурсов Вы хотите использовать существительные, а не глаголы. Это означает, что данные API должны возвращать человека, место или вещь, чаще всего это вещь с определенными атрибутами (например, твит и все его метаданные).

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

Большая дискуссия единственное число против множественного числа существительные. Если вы создавали API-интерфейс Twitter, у вас сначала может быть группа объектов (т. Е. Твит), затем второй объект (т. Е. Идентификатор твита)..

 $ / твит / 15032934882934 $ / твит / 15032934882934 

В этом случае я бы сказал, что форма в единственном числе выглядит лучше. Это особенно верно, когда возвращается только один ресурс. Но нет задокументированного 100% правильного ответа, поэтому делайте все, что подходит для вашего проекта..

Установить тип возврата

Другое соображение возвращаемый тип данных. Большинство веб-пользователей ожидают JSON-контент, так что это, вероятно, лучший вариант. XML - это еще один выбор, если вы хотите предложить оба варианта. Однако JSON является основным типом возврата API среди веб-разработчиков..

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

Если вы только начинаете, пожалуйста, подумайте над этими учебниками:

• Сайт обучения REST API
• Написание простого REST API
• Создание веб-службы RESTful

Дополнительные ресурсы

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

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

Если это ваша цель, рассмотрите следующие ресурсы, которые помогут вам в вашем путешествии.

книги

• REST API Design Rulebook
• RESTful веб-API
• RESTful Web Services Cookbook
• REST без помех: руководство по разработке идеального API

статьи

• Руководство для начинающих по HTTP и REST
• Создание RESTful API
• Руководство по именованию ресурсов RESTful
• Создание REST API с использованием стека MEAN