Что такое код hw_api >insertdocument


Содержание

FPublisher

Web-технологии: База знаний

Документация PHP

hw_api->insertdocument

(No version information available, might be only in CVS)

hw_api->insertdocument — Inserts a new object of type document

Описание

hw_api_object insertdocument ( array $parameter )

This function is a shortcut for hwapi_insert(). It inserts an object with content and sets some of the attributes required for a document.

Список параметров

The parameter array contains the required elements ‘object’, ‘parentIdentifier’ and ‘content’ and the optional elements ‘mode’, ‘parameter’ and ‘attributeSelector’.

See hwapi_insert() for the meaning of each element.

Что такое код hw_api >insertdocument

hw_api->insertdocument — вставляет новый объект типа document.

Описание

object insertdocument (array parameter)

Эта функция является аббревиатурой hwapi_insert() . Она вставляет объект с содержимым и устанавливает некоторые необходимые для документа атрибуты. Массив parameter содержит необходимые элементы ‘object’, ‘parentIdentifier’ и ‘content’ и необязательные элементы ‘mode’, ‘parameter’ и ‘attributeSelector’. См. в hwapi_insert() значение каждого элемента.

Руководство по построению HTTP API

Введение

Данное руководство содержит рекомендации по проектированию HTTP API, которые были почерпнуты из работы API облачной платформы Heroku, кроме того, оно также содержит информацию о новом функционале и внутреннем API в Heroku.

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

При прочтении данной статьи подразумевается, что вы знакомы с основными принципами HTTP и JSON.

Основы

Принцип разделения ответственности

При проектировании старайтесь сохранять простоту системы, разделяя ответственность между различными частями цикла «запрос-ответ». При этом простота принимаемых решений позволит концентироваться на решении все более сложных задач. Запросы и ответы выполняются для получения доступа к определенному ресурсу или набору ресурсов. Для определения сущности, которую необходимо получить, используйте путь и тело ответа для передачи содержимого, а заголовки – для передачи метаданных. Можно передавать все параметры в теле запроса, но, как показывает практика, такое решение является менее гибким. Более правильным подходом будет передача части параметров в заголовках.

Требуйте использования защищенных соединений

Для получения данных при помощи API используйте только защищенные соединения с TLS.
Лучше решением было бы отклонять все запросы, не использующие TLS, а именно запросы по http или на 80-ый порт, во избежание небезопасного обмена данными. В случаях, когда это невозможно, отдавайте ответ 403 Forbidden .

15–16 ноября, Минск, 133–390 br

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

Требуйте наличие версии в заголовке Accept

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

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

Лучше всего – добавить версию в заголовок вместе с другими метаданными, используя заголовок Accept с пользовательским типом содержимого:

Используйте заголовок ETags для кеширования

Включайте заголовок ETags во все запросы, определяя при этом версию возвращаемого ресурса. Это позволит пользователям кэшировать ресурсы и реализовывать условные запросы при помощи использования заголовка If-None-Match , который поможет определить, нужно обновлять кэш или нет.

Используйте Request-ID для интроспекции

Включайте заголовок Request-Id , содержащий в себе UUID значение, в каждый ответ сервера. Регистрируя эти значения на клиенте, сервере или другом сервисе, вы получаете возможность отлаживать и диагностировать проблемы, связанные с запросами.

Разделяйте большие ответы сервера на несколько небольших при помощи заголовка Range

Большие ответы необходимо разбивать на более мелкие, используя заголовок Range . Для получения более детальной информации о заголовках запросов/ответов, кодах состояний и ограничениях изучите Обсуждение использования заголовка Range в API платформы Heroku .

Запросы

Возвращайте соответствующие коды состояний

Возвращайте соотвествующий код состояния HTTP в каждом ответе. Успешные ответы должны содержать такие коды состояний:

  • 200 – GET запрос завершился успешно, синхронный DELETE или PATCH запрос завершился успешно или синхронный PUT запрос обновил существующий ресурс.
  • 201 – Синхронный POST запрос завершился, синхронный PUT запрос создал новый ресурс.
  • 202 – Принят POST , PUT , DELETE или PATCH запрос, который будет обработан асинхронно.
  • 206 – GET запрос завершился успешно, но будет возвращен частичный ответ (см. раздел про заголовок Range ).

Обратите внимание на использование кодов состояния ошибок авторизации и аутентификации:

  • 401 Unauthorized – запрос завершился с ошибкой, поскольку пользователь не прошел аутентификацию.
  • 403 Forbidden – запрос завершился с ошибкой, так как пользователь не авторизовался для получения доступа к определенному ресурсу.

Возвращайте соответствующие коды ошибок для предоставления дополнительной информации об их причинах:

  • 422 Unprocessable Entity – Ваш запрос был распознан, но содержит неверные параметры.
  • 429 Too Many Requests – Превышен лимит запросов, попробуйте позже.
  • 500 Internal Server Error – Проблема на стороне сервера, проверьте состояние сайта и/или сообщите о проблеме.

Для получения более подробной информации о кодах состояния HTTP изучите спецификацию.

По возможности, предоставляйте полные версии ресурсов

Возвращайте пользователям вашего API полное представление ресурса (то есть объект со всеми атрибутами) во всех ответах, где это возможно. Всегда предоставляйте полную версию ресурса в ответах на запросы с кодами состояния 200 и 201 , включая PUT , PATCH и DELETE запросы.

Ответы на запросы с кодом состояния 202 не должны содержать все поля объекта

Ваш API должен принимать сериализованный JSON в теле запроса

Ваш API должен предусматривать возможность передачи сереализованного JSON в теле PUT / PATCH / POST запросов вместо, либо в дополнение к передаваемым данным формы. Таким образом создается симметрия в JSON-ответах:

Будьте последовательны при конструировании пути к ресурсу

Названия ресурсов

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

Действия

Старайтесь проектировать такие конечные url, которые не требуют дополнительных действий для отдельных ресурсов. В случаях, когда это необходимо, добавляйте в общий путь компонент «action» для того, чтобы четко определить эти действия:


Используйте названия компонентов пути и атрибутов в нижнем регистре

Для названий компонентов пути к ресурсу используйте нижний регистр и разделяйте их при помощи дефиса.

Названия атрибутов лучше писать в нижнем регистре, а в качестве разделителя лучше использовать нижнее подчеркивание – таким образом названия полей можно писать без скобок в Javascript:

Ваш API должен поддерживать доступ к ресурсу не только по его id

В некоторых случаях для конечных пользователей неудобен доступ к ресурсу по его идентификатору. Например, пользователю удобнее для доступа к конкретному приложению Heroku использовать название приложения, а не его UUID. В таких случаях нужно организовать доступ как по имени, так и по идентификатору:

Сведите к минимуму количество вложений в пути для доступа к ресурсу

В моделях данных, в которых присутствуют родительские отношения между сущностями, пути доступа к ресурсам могут иметь большой уровень вложенности:

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

Ответы

Предоставляйте UUID запрашиваемых ресурсов

У каждого ресурса по умолчанию должен быть атрибут id . В качестве значений идентификатора ресурса старайтесь всегда использовать UUID. Не используйте идентификаторы, которые не будут уникальными в масштабе вашего сервиса, особенно автоинкрементные идентификаторы.
UUID ресурса выводите в формате 8-4-4-4-12:

Предоставляйте информацию о дате создания и изменения ресурса

По умолчанию ресурс должен хранить информацию о дате его создания created_at и обновления updated_at .

Временные величины должны быть форматированы согласно ISO8601

Принимайте и возвращайте временные данные только в UTC, а выводите в формате ISO8601:

Отношения с внешними сущностями должны быть вынесены во вложенный объект

Внешние отношения должны быть сериализованы как вложенный объект:

А не как поле объекта:

Такой подход позволяет добавить больше информации о связанном объекте без необходимости менять структуру ответа:

Создавайте структурированные ответы в случае возникновения ошибок

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

Показывайте ограничение по количеству запросов

Ограничение по количеству запросов вводится для поддержания работоспособности системы и возможности качественного обслуживания других клиентов. Для расчета ограничений на количество запросов можно использовать алгоритм текущего ведра. Возвращайте оставшееся количество запросов для каждого запроса в заголовке ответа RateLimit-Remaining .

JSON во всех ответах должен быть минимизирован

Лишний пробел увеличивает размер ответа и многие Javascript клиенты для удобочитаемости автоматически отформатируют JSON. Поэтому лучше минимизировать JSON ответы:

Вы можете опционально добавить возможность получать более развернутый ответ, указывая дополнительный параметр (например, ?pretty=true ) или задавая значения для заголовка Accept ( Accept: application/vnd.heroku+json; version=3; indent=4; ).

Артефакты

Предоставляйте удобную для обработки JSON-схему

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

Предоставляйте удобочитаемую документацию

Для того, чтобы разработчики разбирались в принципах работы вашего API, предоставьте им удобную документацию. Если вы создали JSON-схему, используя prmd , как описано выше, вы можете легко сгенерировать Markdown документацию для всех конечных url, используя команду prmd doc .

Вдобавок к описанию конечных url, предоставьте обзор API, включая туда следующую информацию:

  • процесс аутентификации – получение и использование пользовательского токена;
  • стабильность API и его версию, а также информацию о том, как выбрать нужную версию API;
  • общие заголовки запросов и ответов;
  • формат выдачи ошибки;
  • примеры использования API с клиентами на разных языках;

Предоставляйте примеры запросов, которые можно протестировать

Предоставляйте примеры запросов, которые пользователи могут протестировать. Для тестирования этих запросов пользователь должен выполнить минимум действий:

Илон Маск рекомендует:  Bump mapping (pas)

Если вы используете prmd для создания документации, то такие примеры будут сгенерированы автоматически для каждого конечного url.

Опишите стабильность вашего API

Вы можете описать степень стабильности вашего API или отдельных конечных url при помощи установки флагов prototype / development / production .

Для получения дополнительной информации, вы можете изучить документ Политика совместимости Heroku API.

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

Что такое API? Простое объяснение для начинающих

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

Аббревиатура API расшифровывается как «Application Programming Interface» (интерфейс программирования приложений, программный интерфейс приложения). Большинство крупных компаний на определённом этапе разрабатывают API для клиентов или для внутреннего использования. Чтобы понять, как и каким образом API применяется в разработке и бизнесе, сначала нужно разобраться, как устроена «всемирная паутина».

Всемирная паутина и удалённые серверы

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

При введении в адресную строку браузера www.facebook.com на удалённый сервер Facebook отправляется соответствующий запрос. Как только браузер получает ответ, то интерпретирует код и отображает страницу.

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

API как способ обслуживания клиентов

Многие компании предлагают API как готовый продукт. Например, Weather Underground продаёт доступ к своему API для получения метеорологических данных.

Сценарий использования: на сайте небольшой компании есть форма для записи клиентов на приём. Компания хочет встроить в него Google Календарь, чтобы дать клиентам возможность автоматически создавать событие и вносить детали о предстоящей встрече.

Применение API: цель — сервер сайта должен напрямую обращаться к серверу Google с запросом на создание события с указанными деталями, получать ответ Google, обрабатывать его, и передавать соответствующую информацию в браузер, например, сообщение с запросом на подтверждение пользователю.

В качестве альтернативы браузер может сделать запрос к API сервера Google, минуя сервер компании.

Чем API Google Календаря отличается от API любого другого удалённого сервера в сети?

Технически, разница в формате запроса и ответа. Чтобы сгенерировать полную веб-страницу, браузер ожидает ответ на языке разметки HTML, в то время как API Google Календаря вернёт просто данные в формате вроде JSON.

Если запрос к API делает сервер веб-сайта компании, то он и является клиентом (так же, как клиентом выступает браузер, когда пользователь открывает веб-сайт).

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

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

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

Таким образом, когда компания предлагает своим пользователям API, это просто означает, что она создала ряд специальных URL, которые в качестве ответа возвращают только данные.


Такие запросы часто можно отправлять через браузер. Так как передача данных по протоколу HTTP происходит в текстовом виде, браузер всегда сможет отобразить ответ. Например, через браузер можно напрямую обратиться к API GitHub (https://api.github.com/users/petrgazarov), причём без маркера доступа, и получить вот такой ответ в формате JSON:

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

Ещё несколько примеров API

Слово «application» (прикладной, приложение) может применяться в разных значениях. В контексте API оно подразумевает:

  • фрагмент программного обеспечения с определённой функцией,
  • сервер целиком, приложение целиком или же просто отдельную часть приложения.

Любой фрагмент ПО, который можно чётко выделить из окружения, может заменять букву «А» в англоязычной аббревиатуре, и тоже может иметь некоторого рода API. Например, при внедрении в код разработчиком сторонней библиотеки, она становится частью всего приложения. Будучи самостоятельным фрагментом ПО, библиотека будет иметь некий API, который позволит ей взаимодействовать с остальным кодом приложения.

В объектно-ориентированном проектировании код представлен в виде совокупности объектов. В приложении таких объектов, взаимодействующих между собой, могут быть сотни. У каждого из них есть свой API — набор публичных свойств и методов для взаимодействия с другими объектами в приложении. Объекты могут также иметь частную, внутреннюю логику, которая скрыта от окружения и не является API.

Пишем документацию API при помощи RAML

Удобство работы с любым API во многом зависит от того, как написана и оформлена его документация. Cейчас мы ведём работу по стандартизации и унификации описания всех наших API, и вопросы документирования для нас особенно актуальны.
После долгих поисков мы решили оформлять документацию в формате RAML . Так называется специализированный язык для описания REST API. О его возможностях и преимуществах мы расскажем в этой статье.

Почему RAML

Как нужно документировать API? Вопрос этот не так прост, как может показаться на первый взгляд.
Первый и самый простой вариант, который приходит на ум — представить описание к API в виде обычного текстового документа. Так делают очень многие (в том числе и очень известные компании). Мы тоже не раз пользовались этим способом. При всей своей простоте он обладает следующими недостатками:

  • текстовую документацию сложно поддерживать в актуальном состоянии;
  • зачастую словесные описания API оказываются недостаточно наглядными;
  • сфера использования «словесной» документации очень ограничена (например, на её основе нельзя сгенерировать интерактивную тестовую страницу).

Чтобы упростить процесс документирования, можно использовать специализированные инструменты и сервисы. Как правило, они генерируют документацию на основе описания в некотором стандартизованном формате — обычно это JSON или Markdown.

Ни один из этих форматов для написания документации не подходит. JSОN был изначально создан для обмена данными в вебе. При использовании его для других целей поневоле приходится прибегать к помощи «костылей» — например, кастомных полей, начинающихся со знака $. Кроме того, составлять описания в формате JSON вручную — дело достаточно рутинное и утомительное (в особенности если речь идёт об описаниях большого размера).

На описанные выше трудности обращали внимание многие пользователи популярного инструмента Swagger . Вскоре разработчики Swagger решили упростить работу по написанию спецификаций и создали фирменный редактор с поддержкой формата YAML.

Конечно, YAML гораздо удобнее, чем JSON. Но и его использование сопряжено с определёнными трудностями. Дело в том, что в описаниях API всегда имеются повторяющиеся элементы (например, схема ответа, которая может быть одинаковой для разных типов HTTP-запросов), которые приходится всякий раз прописывать вручную. Вот если бы можно их было раз и навсегда прописать в отдельном файле и ссылаться на него в случае небходимости…. Но, увы, пока что такой возможности нет.

Что касается формата Markdown (он используется, например, в API BluePrint ), то предназначен в первую очередь для оформления текста, а не для использования в качестве основы для генерирования. Приспособить его под документирование API очень сложно. По этой же причине не привели к каким-либо заметным результатам попытки cоздать формат описания API на базе XML — например, язык WADL (Web Application Desription Language), разработанный компанией Sun Microsystems ещё в 2009 году, но так и не получивший широкого распространения.

Создатели проекта RAML (эта аббревиатура означает RESTful API Modeling Language — язык для моделирования REST API ) предприняли попытку разработать язык, предназначенный исключительно для описания API и исправить недочёты, свойственные другим форматам. Первая версия спецификации RAML была опубликована в 2013 году. Основным разработчиком RAML является компания MuleSoft; в проекте также принимают участие представители таких известных компаний, как Cisco, PayPal, ВoxInc. и других.

Несомненными преимуществами RAML являются:

  • простой и логичный синтаксис, основанный на формате YAML;
  • поддержка наследования и возможность подключения внешних файлов спецификаций.

Дополнительным плюсом является наличие большого количества конвертеров, парсеров и генераторов интерактивной документации. О некоторых из них мы расскажем ниже, а пока перейдём к обзору особенностей синтаксиса RAML.

Краткое введение в RAML

Структура документа

Файл спецификаций на RAML состоит из следующих структурных элементов:

  • вводная часть («шапка»);
  • схема безопасности;
  • описание профилей;
  • описание объектов и методов;
  • описание ответов.

Рассмотрим эти элементы подробнее.

Вводная часть

Каждый документ на RAML начинается с вводной части, которая включает четыре обязательных элемента:

  • версия RAML;
  • имя документа;
  • URI, по которому доступен API;
  • версия API, описываемая в документации.

Выглядит это так:

Вводная часть может также включать различную дополнительную информацию — например, сведения об используемом протоколе для связи с API:

Можно во вводной части прописать и метаданные файла документации:

Схемы безопасности

Чтобы начать работать с любым API, нужно пройти процедуру авторизации. Она может осуществляться разными способами: через OAuth, с помощью токенов, либо посредством простой HTTP-аутентификации. Для описания этой процедуры в RAML используются схемы безопасности (security schemes).
Рассмотрим в качестве примера, как описывается авторизация с использованием протокола OAuth2:

Приведённый фрагмент содержит следующую информацию:

  • в параметре type указывается, что в API используется авторизация по протоколу OAuth2;
  • далее указывается, что авторизационные данные можно передавать либо в заголовке Authorization, либо в query-параметре access_token;
  • после этого следуют возможные коды ответов и их описания;
  • в конце раздела, в секции settings указываются URL для авторизации, URL для получения токена, а также необходимые для аутентификации параметры (authorization grants).

Для удобства схемы безопасности можно сохранять в отдельных файлах .raml или .yml, и затем обращаться к ним в случае необходимости:

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

Почитать более подробно о схемах безопасности и ознакомиться с конкретными примерами можно здесь (раздел Security).

Объекты и методы

Далее перечисляются основные объекты и пути к ним, а также HTTP-методы, которые используются с этими объектами:

В приведённом примере описывается API, с помощью которого можно работать с документами. Мы можем скачивать документы на локальную машину (GET), изменять cуществующие документы (PUT) и загружать новые (POST). С каждым отдельным документом () мы можем также выполнять следующие операции: загрузка на локальную машину (GET) и удаление (DELETE).
HTTP-заголовки, используемые с тем или иным методом, описываются при помощи свойства headers, например:

Обратите внимание на свойство required: оно указывает, является ли заголовок обязательным (true) или необязательным (false).
В описании объектов и методов могут использоваться многочисленные дополнительные параметры. Рассмотрим следующий пример:

Здесь мы указываем, что каждый из документов, доступ к которым можно получить через API, имеет собственный идентификационный код в виде строки (type: string), а также описываем формат этого кода с помощью регулярных выражений.

Свойства description, type и pattern можно использовать и в описаниях методов, например:

В описании метода POST мы указываем параметры, которые нужно передать в теле запроса для добавления нового документа: ID, имя и имя автора. Каждый из этих параметров является строкой (type: string). Обратите внимание на свойство required: оно указывает, является ли параметр обязательным (true) или необязательным (false).

Для каждого метода можно прописать индивидуальную схему безопасности:

Query-параметры

Для каждого метода в документации можно указать query-параметры, которые будут использоваться в запросе. Для каждого query-параметра указываются следующие характеристики: имя, тип, описание и пример:

Профили

Чтобы избежать лишних повторений в описаниях, в RAML используются профили (traits), которые прописываются во вводной части документа:

В дальнейшем к профилю можно обращаться при описании любых методов:

Более подробно о профилях и особенностях их использования можно почитать в официальной документации (раздел Traits).

Описание ответа


В описании ответа обязательно указывается его код. Также в описание можно добавить схему (schema) — перечисление входящих в ответ параметров и их типов. Можно также привести пример конкретного ответа (example).

Cхемы ответов можно сохранять в отдельных файлах формата .yml или .raml и обращаться к ним в других частях документации:

Визуализация и генерация документации

RAML2HTML и другие конвертеры

Несмотря на то, что RAML — формат относительно новый, для него уже разработано достаточное количество конвертеров и парсеров. В качестве примера можно привести ram2htmtl , генерирующий на основе описания в формате RAML статическую HTML-страницу.
Устанавливается он при помощи менеджера пакетов npm:

Чтобы сконвертировать RAML-файл в HTML, достаточно выполнить простую команду:

Поддерживается возможность создания собственных шаблонов для HTML-файлов (подробнее об этом см. в документации на GitHub по ссылке выше).
Из других конвертеров рекомендуем также обратить внимание на RAML2Wiki и RAML2Swagger .

API Designer

Компания Mulesoft (один из активных участников проекта RAML) создала специальный онлайн-инструмент, с помощью которого можно упростить работу по написанию документации и последующему тестированию API. Называется он API Designer .
Чтобы начать им пользоваться, нужно сначала зарегистрироваться на сайте. После этого можно приступать к работе. API designer предоставляет, во-первых, удобный интерактивный редактор для написания документации онлайн, а во-вторых — платформу для тестирования.
Выглядит всё это так:

В правой части страницы автоматически генерируется интерактивная документация. Здесь же можно и протестировать API: для этого достаточно просто развернуть описание нужного запроса и нажать на кнопку Try it.

API Designer позволяет также загружать RAML-файлы с локальной машины. Поддерживается импорт файлов описаний API для Swagger.
Кроме того, API Designer хранит статистику тестовыx запросов к API.

API console

API console — полезный инструмент, разработанный всё той же компанией MuleSoft. С его помощью можно прямо в браузере генерировать документацию к API. Файлы спецификаций можно как загрузить с локальной машины, так и указать ссылку на внешний источник:

В состав API Console входит несколько файлов-образцов, представляющих собой описания API популярных веб-сервисов: Twitter, Instagram, Box.Com, LinkedIn. Мы попробовали сгенерировать на основе одного из низ документацию — выглядит вполне симпатично:

Илон Маск рекомендует:  Использование java классов и объектов в oracle8i

Документация, получаемая на выходе, является интерактивной: в ней можно не только прочитать описание API, но и выполнить тестовые запросы.

Заключение

В этой статье мы рассмотрели основные возможности RAML. Его несомненными преимуществами являются простота и логичность. Надеемся, что в скором будущем RAML получить ещё более широкое распространение и займёт достойное место в ряду инструментов для документирования API.
Если у вас есть вопросы — добро пожаловать в комментарии. Будем также рады, если вы поделитесь собственным опытом использования RAML на практике.

DATA API

Соглашения

Приняты следующие соглашения при использовании Data API:

  • Пустые поля всегда возвращаются в ответе со значением null . В случае массива возвращается пустой массив, в случае объекта возвращается пустой объект;
  • Все поля связанные с датой и временем передаются в формате YYYY-MM-DD hh:mm:ss;
  • Запросы к API выполняются всегда с помощью метода POST;
  • Все параметры в запросах/ответах, а также в структурах данных в формате JSON и название методов именуются в стиле Snake Case — разделение слов через нижнее подчёркивание;
  • Данные возвращаются только в JSON формате согласно спецификации RFC 7159. Заголовок Accept игнорируется;
  • Кодировка данных UTF-8;
  • Заголовок Content-Type должен быть «application/json; charset=UTF-8» ;
  • Заголовок Content-Length должен содержать корректную длину сообщения, следуя спецификации HTTP/1.1

Добавить IP-адрес в список разрешенных

По умолчанию доступ к API запрещен всем, чтобы можно было делать запросы необходимо IP-адрес хоста с которого делается запрос добавить в белый список. Это можно сделать через личный кабинет «Администратор -> Аккаунт -> Правила и настройки безопасности» вкладка «API».

Если необходимо разрешить доступ всем IP-адресам, то нужно добавить в список разрешенных 0.0.0.0/0

Если запрос делается из под агента, то его IP адрес должен быть добавлен в белый список клиентского аккаунта

Пользователи API и аутентификация

К пользователям и ключам доступа применяются права доступа аналогичные правам доступа в личном кабинете

Доступ по ключу

Ключи генерируются на уровне пользователя в разделе личного кабинета «Аккаунт» → «Управление пользователями»
Существует два типа ключей:

Постоянный ключ имеет неограниченное время действия.
Временный ключ имеет конкретную дату окончания действия ключа.

Доступ по логину и паролю

Используется аутентификация с использованием сессий

Отчёт по запросам к API

В личном кабинете «Отчёты»->»Служебные»->»Запросы к API» можно построить отчёт по запросам к API

Базовый URL для доступа к API

Базовый URL для доступа к API соответствует следующему шаблону:

— https;

  • — api.comagic.ru, api.uiscom.ru;
  • — версия API (см. раздел Версионность)
  • Версионность

    Текущая версия Data API 2.0

    Data API поддерживает версионность. Версия указывается в базовом URL как vX.Y , где X — номер мажорной версии, Y — номер минорной версии

    Если была выпущена новая версия, то старая считается устаревшей и соответственно при обращении к старой версии API в мета-параметрах (см. раздел Мета-параметры) будет возвращаться параметр «current_version_deprecated» со значением «true»

    Максимальное количество поддерживаемых версий — 2
    Период поддержки устаревшей версии 2 месяца

    Лимиты и ограничения

    Баллы списываются только за успешные запросы, т.е в отчете по запросам к API (см. раздел Отчёт по запросам к API) он помечен как успешный.

    Информация о лимитах возвращается во всех ответах в мета-парметрах (см. раздел Мета-параметры) кроме случаев когда лимиты не учитываются;

    Лимиты построены по бальной системе, т.е каждый метод имеет свой вес. Вызов метода уменьшает доступные дневные/минутные баллы на размер веса вызываемого метода

    Информация о лимитах в мета-параметрах:

    Название параметра Описание
    day_limit Текущий лимит баллов в день
    day_remaining Какое количество баллов осталось до достижения дневного лимита
    day_reset Время в секундах через которое дневной лимит будет сброшен
    minute_limit Текущий лимит баллов за минуту
    minute_remaining Какое количество баллов осталось до достижения минутного лимита
    minute_reset Время в секундах через которое минутный лимит будет сброшен

    Методы и их стоимость в баллах

    Тип операции Стоимость в баллах
    Все операции 1

    Расширение лимитов

    На странице «Аккаунт» -> «Тарифы и опции» в личном кабинете можно расширить лимиты.

    Обработка ошибок

    Параметры сообщения об ошибке

    Название Тип Обязательный Описание
    error object да Объект с содержимым ошибки
    code number да Не уникальный код ошибки (см. раздел Группы кодов ошибок )
    message string да Cообщение об ошибке
    data object да Объект с деталями ошибки
    mnemonic string да Уникальный текстовый код ошибки. При обработке ошибок рекомендуется использовать этот параметр.
    value string нет Содержит то, что передал пользователь без изменений


    В некоторых случаях может отсутствовать. К примеру, обязательный параметр вообще не был заполнен.

    extended_helper string нет Ссылка на более подробное описание ошибки и возможные решения params object нет Карта подстановок параметров для шаблона с текстом об ошибке. Т.е. содержит динамически изменяемые значения, к примеру, лимиты. Значения указанные в этом параметре могут быть использованы в сообщениях об ошибках в интерфейсе, который базируется на Data API. field string нет Название параметра, с которым связана ошибка

    Вложенные параметры отображаются через разделитель точка «.»
    К примеру: «employee.phone_number»

    JSON структура ошибки

    Группы кодов ошибок

    Код ошибки Описание
    -32700 Ошибки связанные с валидацией JSON
    -32600 Ошибки связанные с валидацией параметров запроса — id , jsonrpc
    -32601 Ошибки связанные с методом
    -32602 Ошибки связанные с валидацией параметров в вызываемом методе
    -32603 Внутренние ошибки JSON RPC сервера
    -32001 Ошибки аутентификации и ошибки с ключами
    -32003 Ошибки с правами доступа — ip адрес не в белом списке, нет прав у пользователя
    -32004 Ошибки связанные с неверной последовательностью вызываемых методов
    -32007 Ошибки связанные с виртуальным номером
    -32008 Ошибки связанные с компонентами
    -32009 Ошибки связанные с аккаунтом
    -32029 Ошибки связанные с лимитами
    -32099 Ошибки связанные с поддержкой различных частей спецификации JSON RPC 2.0 — Групповые операции, Уведомления

    Список ошибок общих для всех методов

    Текст сообщение Код Мнемоника Описание
    Invalid Request The JSON sent is not a valid Request object -32600 invalid_request Ошибки связанные с валидацией параметров запроса — id , jsonrpc
    Access token has been expired -32001 access_token_expired Применяется только к постоянному токену. Если время жизни постоянного токена истекло, то возвращается указанная ошибка
    Access token has been blocked -32001 access_token_blocked Если постоянный токен заблокирован, то возвращается указанная ошибка
    Access token is invalid -32001 access_token_invalid Указанная ошибка возвращается если постоянный/временный токен не найден
    Limit per has been exceeded. Value of current limit per is -32029 limit_exceeded Лимит превышен
    You need at least on of the following components to access this method: -32008 method_component_disabled Если не подключен компонент, который требуется для работы метода
    You need at least on of the following components to access this paremeter: -32008 parameter_component_disabled Если не подключен компонент, который нужен для заполнения параметра и создания сущности
    Your IP is not whitelisted -32003 ip_not_whitelisted IP адрес с которого делается запрос не находится в белом списке адресов. Если запрос делается из под агента, то ваш IP адрес должен быть в списках разрешеных адресов внутри клиентского аккаунта
    Login or password is wrong -32001 auth_error Неправильный логин или пароль
    Your account has been disabled, contact the support service -32009 account_inactive Аккаунт заблокирован
    Internal error, contact the support service -32603 internal_error Внутренняя ошибка, необходимо обратиться в службу технической поддержки
    Data supplied is of wrong type -32602 data_type_error К примеру, если ожидаем string а передали int
    The method does not exist / is not available -32601 method_not_found Вызываемый метод не найден
    Permission denied -32003 forbidden Нет прав на доступ к методу или API, или запрещено выполнять какое-либо действие
    Invalid JSON was received by the server. -32700 parse_error Ошибка валидации JSON
    Batch operations not supported -32099 batch_opreations_not_supported Групповые операции не поддерживаются
    Notifications not supported -32099 notifications_not_supported Был потерян параметр id в запросе. См. раздел Общие параметры для всех методов»
    The required parameter has been missed -32602 required_parameter_missed Обязательный параметр не передали
    Invalid parameter value -32602 invalid_parameter_value Возвращается во всех случаях, если было передано некорректное значение параметра или переданное значение не соответствует требуемому формату ввода
    Unexpected method parameter(s) -32602 unexpected_parameters Если в «params» были переданы параметры которые не предусмотрены JSON структурой метода или указан параметр для сортировки, фильтрации и выборки, который не существует
    The combination of parameters is not permitted -32602 invalid_parameters_combination Если параметры указанные в методе находятся в недопустимой комбинации или имеют зависмость друг от друга. Нужно смотреть документацию по методу и его параметрам.
    -32602 error Динамические ошибки

    Список ошибок для методов с глаголом get

    Текст ошибки Код Мнемоника Описание
    Invalid parameter value -32602 invalid_parameter_value Если в фильтрах было передано некорректное значение для regexp, jsquery или любых значений не соответствующих документации
    Sort by parameter is prohibited -32602 sort_prohibited Сортировка по параметру запрещена и невозможна, так как параметр для сортировки не находится в списке разрешенных для сортировки
    Filter by parameter is prohibited -32602 filter_prohibited Фильтрация по параметру запрещена и невозможна, так как параметр для фильтрации не находится в списке разрешенных для фильтрации
    Max value of requested date interval is 3 months -32602 date_interval_limit_reached Если в запросе период между указанными датами в date_from и date_till превышает 3 месяца. В основном ошибка актуальна только для методов получения отчетов, но не для всех.

    Список ошибок общих для методов с глаголом delete

    Текст ошибки Код Мнемоника Описание
    Entity not found -32602 entity_not_found Если передан уникальный идентификатор сущности, которая не найдена
    You have interdependet entities -32602 dependency_error Удаляемая сущность используется в других сущностях. Чтобы удалить, необходимо убрать удаляемую сущность из всех возможных мест где она используется
    Permission denied -32602 forbidden Удалить сущность невозможно так как она системная, к примеру группа «Черный список» в адресной книге

    Список ошибок общих для методов с глаголом create и update, set, unset

    Текст ошибки Код Мнемоника Описание
    Entity not found -32602 entity_not_found Если передан уникальный идентификатор сущности, которая не найдена
    Duplicate entity -32602 duplicate_entity Если сущность уже существует
    A new data limit has been exceeded -32602 data_limit_exceeded Ошибка возникает в случае, если было достигнуто максимальное количество данных.
    Action is not allowed for your tariff plan. You need contact support service or change your tariff plan settings in your account -32602 tariff_restrictions Любые ограничения тарифного плана
    This value is already used by another entity -32602 already_in_use Значение указанного параметра уже используется в другой сущности. К примеру, виртуальный номер уже используется в другой рекламной кампании.

    Групповые операции

    Функционал не поддерживается

    Принцип именования методов

    Имя JSON-RPC метода состоит из двух частей разделенных точкой: глагола и имени объекта.

    Имя объекта выбирается как существительное во множественном числе, отражающее бизнес-сущность, например subscribers .

    Имя метода должно начинаться с глагола, отражающего суть операции.

    Глаголы используемые в именовании методов

    Глагол Описание
    create Добавляет сущность.
    get Возвращает список отсортированных и отфильтрованных данных с помощью критериев фильтрации и методов сортировки. К запросу возможно применить лимит и постраничный вывод на количество получаемых данных (см. раздел Постраничный вывод). С помощью критериев фильтрации может быть так же получена одна запись, по ёё уникальному идентификатору (см. раздел Критерии фильтрации). В специальном мета-параметре возвращается общее количество записей (см. раздел Мета-параметры). С помощью специального параметра можно указать какие поля возвращать в ответном сообщении (см. раздел Представление возвращаемых данных).
    update Обновляет сущность с определённым идентификатором.

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

    delete Удаляет сущность с определённым идентификатором. add Связь одного объекта с другим. enable Подключение объекта disable Отключение объекта set Простановка свойства на другой объект, к примеру, установка тега на обращение unset Снятие свойства с другого объека, к примеру, снятие тега с обращения

    Критерии фильтрации

    Фильтрация данных применяется только к глаголу «get» (см. раздел «Глаголы используемые в именовании методов» с помощью необязательного примитива «filter» , который является объектом и может содержать:

    1. Простой фильтр;
    2. Дерево фильтров которое содержит простые фильтры с условиями.

    Простой фильтр — это объект, который содержит в себе обязательные примитивы:

    • field — поле сущности к которой будет применяться фильтрация (список заранее определён для метода);
    • operator — оператор фильтрации. Список всех операторов можно получить в разделе «Операторы фильтрации»;
    • value — значение для оператора фильтрации. Необязательное поле, если оно отсутствует, то считается пустота.

    Дерево фильтров содержит специальный примитив «filters» , который может содержать в себе как простые фильтры, так и дерево фильтров.

    Возможные ошибки при фильтрации

    Текст Код Мнемоника Описание
    Filter by parameter is prohibited -32602 filter_prohibited Фильтрация по параметру запрещена и невозможна, так как параметр для фильтрации не находится в списке разрешенных для фильтрации
    Unexpected method parameter(s) -32602 unexpected_parameters Передан ошибочный параметр или параметр, которого не существует

    Пример JSON структуры простого фильтра

    Получаем список записей у которых поле «name» имеет имя «Bob»

    Пример JSON структуры дерева фильтров с одним уровнем вложенности

    Получаем список записей у которых поле «name» имеет имя «Bob» и его возраст 25 лет

    Пример JSON структуры дерева фильтров с двойным уровнем вложенности

    Получаем список записей у которых поле «name» имеет имя «Bob» и его возраст 25 лет или список записей у которых поле «name» имеет имя «Dexter» и его возраст 2 года

    Пример JSON структуры дерева фильтров с тройным уровнем вложенности

    Условие запроса ((addv_comp_ >

    Операторы фильтрации

    Фильтрация null и not null будет =null, !=null

    Оператор Описание Учёт регистра строк Тип данных
    = Равно да number, string, null, boolean, iso8601, enum
    != Не равно да number, string, null, boolean, iso8601, enum
    Меньше чем number, iso8601
    > Больше чем number, iso8601
    Меньше или равно number, iso8601
    >= Больше или равно number, iso8601
    like Начинается с, Заканчивается на, Содержит
    да string regexp Posix да string jsquery PostgreSQL jsquery да object, array in Массив значений в отношении «or» да number, string, enum

    Сортировка данных

    Сортировка данных применяется только к глаголу «get» (см. раздел «Глаголы используемые в именовании методов») с помощью массива объектов сортировки со следующими примитивами:

    • field — поле по которому производится сортировка;
    • order — направления сортировки. Возможные значения «asc» / «desc» . «asc» — по возрастанию, «desc» — по убыванию. Параметр необязателен. Значение по умолчанию «asс» .

    Список полей по которым можно производить сортировку определяется индивидуально для каждого метода.

    Возможные ошибки при сортировки

    Текст ошибки Код Мнемоника Описание
    Sort by parameter is prohibited -32602 sort_prohibited Сортировка по параметру запрещена и невозможна, так как параметр для сортировки не находится в списке разрешенных для сортировки
    Unexpected method parameter(s) -32602 unexpected_parameters Передан ошибочный параметр или параметр, которого не существует

    Постраничный вывод

    Постраничный вывод может быть применён к глаголу «get» (см. раздел «Глаголы используемые в именовании методов»). Для выполнения пагинации данных используются следующие параметры:

    Параметр Значение по умолчанию Допустимое значение Описание
    offset 100 000 Сдвиг, определяет с какого номера записи возвращать «limit» записей
    limit 1000 10 000 Размер возвращаемых данных (количество записей)

    Мета-параметры

    Возвращаются при использовании глагола «get» (см. раздел «Глаголы используемые в именовании методов»).

    Присутствуют как в ошибочном, так и в успешном ответе

    Параметр «api_version» возвращается только для версий которые deprecated.


    Представление возвращаемых данных

    Отдельный список возвращаемых столбцов

    В глаголе получения данных «get» (см. раздел «Глаголы используемые в именовании методов») может быть указан специальный необязательный примитив «fields» с типом массив, который может содержать список полей которые необходимо показать в выводе. Если примитив «fields» не используется, то в выводе показываются все поля по умолчанию для вызываемого метода.

    Список полей индивидуален для каждого метода.

    Возможные ошибки в представлении возвращаемых данных

    Текст Код Мнемоника Описание
    Unexpected method parameter(s) -32602 unexpected_parameters Передан ошибочный параметр или параметр, которого не существует

    Общие поля для всех методов

    Название Тип Обязательный Допустимые значения Описание
    id string или number да Уникальный идентификатор запроса к API, который используется для связи запроса с ответом. Рекомендуется делать в виде уникального хэша или случайного числа .
    method string да Вызываемый метод
    jsonrpc string да 2.0 Номер спецификации JSON-RPC
    params object да Содержит тело запроса к API. В зависимости от вызываемого метода тело запроса меняется.

    Аутентификация

    Метод login.user
    Описание Вход и получение ключа сессии аутентификации
    Кому доступен Партнёр, Клиент

    Параметры запроса

    Название Тип Обязательный Допустимые значения Описание
    login string да Логин пользователя
    password string да Пароль пользователя

    Параметры ответа

    Название Тип Обязательный Описание
    access_token string да Ключ сессии аутентификации
    expire_at number да Timestamp когда выданный токен перестанет быть валидным
    app_id number да Уникальный идентификатор клиента

    Время жизни полученного ключа сессии аутентификации после вызова метода «login.user» — 1 час. По истечению времени жизни ключа сессии его необходимо запрашивать заново, т.е. вызывать метод «login.user» .

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

    hw_api->insertdocument

    (PHP 4, PHP 5 hw_api->insertdocument — Inserts a new object of type document

    Описание

    This function is a shortcut for hwapi_insert() . It inserts an object with content and sets some of the attributes required for a document.

    Список параметров

    The parameter array contains the required elements ‘object’, ‘parentIdentifier’ and ‘content’ and the optional elements ‘mode’, ‘parameter’ and ‘attributeSelector’.

    See hwapi_insert() for the meaning of each element.

    hw_api->insertdocument

    (PHP 4, PHP 5 hw_api->insertdocument — Inserts a new object of type document

    Описание

    This function is a shortcut for hwapi_insert() . It inserts an object with content and sets some of the attributes required for a document.

    Список параметров

    The parameter array contains the required elements ‘object’, ‘parentIdentifier’ and ‘content’ and the optional elements ‘mode’, ‘parameter’ and ‘attributeSelector’.

    See hwapi_insert() for the meaning of each element.

    Что такое код hw_api >insertdocument

    hw_api->insertdocument — вставляет новый объект типа document.

    Описание

    object insertdocument (array parameter)

    Эта функция является аббревиатурой hwapi_insert() . Она вставляет объект с содержимым и устанавливает некоторые необходимые для документа атрибуты. Массив parameter содержит необходимые элементы ‘object’, ‘parentIdentifier’ и ‘content’ и необязательные элементы ‘mode’, ‘parameter’ и ‘attributeSelector’. См. в hwapi_insert() значение каждого элемента.

    Руководство по построению HTTP API

    Введение

    Данное руководство содержит рекомендации по проектированию HTTP API, которые были почерпнуты из работы API облачной платформы Heroku, кроме того, оно также содержит информацию о новом функционале и внутреннем API в Heroku.

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

    При прочтении данной статьи подразумевается, что вы знакомы с основными принципами HTTP и JSON.

    Основы

    Принцип разделения ответственности

    При проектировании старайтесь сохранять простоту системы, разделяя ответственность между различными частями цикла «запрос-ответ». При этом простота принимаемых решений позволит концентироваться на решении все более сложных задач. Запросы и ответы выполняются для получения доступа к определенному ресурсу или набору ресурсов. Для определения сущности, которую необходимо получить, используйте путь и тело ответа для передачи содержимого, а заголовки – для передачи метаданных. Можно передавать все параметры в теле запроса, но, как показывает практика, такое решение является менее гибким. Более правильным подходом будет передача части параметров в заголовках.

    Требуйте использования защищенных соединений

    Для получения данных при помощи API используйте только защищенные соединения с TLS.
    Лучше решением было бы отклонять все запросы, не использующие TLS, а именно запросы по http или на 80-ый порт, во избежание небезопасного обмена данными. В случаях, когда это невозможно, отдавайте ответ 403 Forbidden .

    15–16 ноября, Минск, 133–390 br

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

    Требуйте наличие версии в заголовке Accept

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

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

    Лучше всего – добавить версию в заголовок вместе с другими метаданными, используя заголовок Accept с пользовательским типом содержимого:

    Используйте заголовок ETags для кеширования

    Включайте заголовок ETags во все запросы, определяя при этом версию возвращаемого ресурса. Это позволит пользователям кэшировать ресурсы и реализовывать условные запросы при помощи использования заголовка If-None-Match , который поможет определить, нужно обновлять кэш или нет.

    Используйте Request-ID для интроспекции

    Включайте заголовок Request-Id , содержащий в себе UUID значение, в каждый ответ сервера. Регистрируя эти значения на клиенте, сервере или другом сервисе, вы получаете возможность отлаживать и диагностировать проблемы, связанные с запросами.

    Разделяйте большие ответы сервера на несколько небольших при помощи заголовка Range

    Большие ответы необходимо разбивать на более мелкие, используя заголовок Range . Для получения более детальной информации о заголовках запросов/ответов, кодах состояний и ограничениях изучите Обсуждение использования заголовка Range в API платформы Heroku .

    Запросы

    Возвращайте соответствующие коды состояний

    Возвращайте соотвествующий код состояния HTTP в каждом ответе. Успешные ответы должны содержать такие коды состояний:


    • 200 – GET запрос завершился успешно, синхронный DELETE или PATCH запрос завершился успешно или синхронный PUT запрос обновил существующий ресурс.
    • 201 – Синхронный POST запрос завершился, синхронный PUT запрос создал новый ресурс.
    • 202 – Принят POST , PUT , DELETE или PATCH запрос, который будет обработан асинхронно.
    • 206 – GET запрос завершился успешно, но будет возвращен частичный ответ (см. раздел про заголовок Range ).

    Обратите внимание на использование кодов состояния ошибок авторизации и аутентификации:

    • 401 Unauthorized – запрос завершился с ошибкой, поскольку пользователь не прошел аутентификацию.
    • 403 Forbidden – запрос завершился с ошибкой, так как пользователь не авторизовался для получения доступа к определенному ресурсу.

    Возвращайте соответствующие коды ошибок для предоставления дополнительной информации об их причинах:

    • 422 Unprocessable Entity – Ваш запрос был распознан, но содержит неверные параметры.
    • 429 Too Many Requests – Превышен лимит запросов, попробуйте позже.
    • 500 Internal Server Error – Проблема на стороне сервера, проверьте состояние сайта и/или сообщите о проблеме.

    Для получения более подробной информации о кодах состояния HTTP изучите спецификацию.

    По возможности, предоставляйте полные версии ресурсов

    Возвращайте пользователям вашего API полное представление ресурса (то есть объект со всеми атрибутами) во всех ответах, где это возможно. Всегда предоставляйте полную версию ресурса в ответах на запросы с кодами состояния 200 и 201 , включая PUT , PATCH и DELETE запросы.

    Ответы на запросы с кодом состояния 202 не должны содержать все поля объекта

    Ваш API должен принимать сериализованный JSON в теле запроса

    Ваш API должен предусматривать возможность передачи сереализованного JSON в теле PUT / PATCH / POST запросов вместо, либо в дополнение к передаваемым данным формы. Таким образом создается симметрия в JSON-ответах:

    Будьте последовательны при конструировании пути к ресурсу

    Названия ресурсов

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

    Действия

    Старайтесь проектировать такие конечные url, которые не требуют дополнительных действий для отдельных ресурсов. В случаях, когда это необходимо, добавляйте в общий путь компонент «action» для того, чтобы четко определить эти действия:

    Используйте названия компонентов пути и атрибутов в нижнем регистре

    Для названий компонентов пути к ресурсу используйте нижний регистр и разделяйте их при помощи дефиса.

    Названия атрибутов лучше писать в нижнем регистре, а в качестве разделителя лучше использовать нижнее подчеркивание – таким образом названия полей можно писать без скобок в Javascript:

    Ваш API должен поддерживать доступ к ресурсу не только по его id

    В некоторых случаях для конечных пользователей неудобен доступ к ресурсу по его идентификатору. Например, пользователю удобнее для доступа к конкретному приложению Heroku использовать название приложения, а не его UUID. В таких случаях нужно организовать доступ как по имени, так и по идентификатору:

    Сведите к минимуму количество вложений в пути для доступа к ресурсу

    В моделях данных, в которых присутствуют родительские отношения между сущностями, пути доступа к ресурсам могут иметь большой уровень вложенности:

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

    Ответы

    Предоставляйте UUID запрашиваемых ресурсов

    У каждого ресурса по умолчанию должен быть атрибут id . В качестве значений идентификатора ресурса старайтесь всегда использовать UUID. Не используйте идентификаторы, которые не будут уникальными в масштабе вашего сервиса, особенно автоинкрементные идентификаторы.
    UUID ресурса выводите в формате 8-4-4-4-12:

    Предоставляйте информацию о дате создания и изменения ресурса

    По умолчанию ресурс должен хранить информацию о дате его создания created_at и обновления updated_at .

    Временные величины должны быть форматированы согласно ISO8601

    Принимайте и возвращайте временные данные только в UTC, а выводите в формате ISO8601:

    Отношения с внешними сущностями должны быть вынесены во вложенный объект

    Внешние отношения должны быть сериализованы как вложенный объект:

    А не как поле объекта:

    Такой подход позволяет добавить больше информации о связанном объекте без необходимости менять структуру ответа:

    Создавайте структурированные ответы в случае возникновения ошибок

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

    Показывайте ограничение по количеству запросов

    Ограничение по количеству запросов вводится для поддержания работоспособности системы и возможности качественного обслуживания других клиентов. Для расчета ограничений на количество запросов можно использовать алгоритм текущего ведра. Возвращайте оставшееся количество запросов для каждого запроса в заголовке ответа RateLimit-Remaining .

    JSON во всех ответах должен быть минимизирован

    Лишний пробел увеличивает размер ответа и многие Javascript клиенты для удобочитаемости автоматически отформатируют JSON. Поэтому лучше минимизировать JSON ответы:

    Вы можете опционально добавить возможность получать более развернутый ответ, указывая дополнительный параметр (например, ?pretty=true ) или задавая значения для заголовка Accept ( Accept: application/vnd.heroku+json; version=3; indent=4; ).

    Артефакты

    Предоставляйте удобную для обработки JSON-схему

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

    Предоставляйте удобочитаемую документацию

    Для того, чтобы разработчики разбирались в принципах работы вашего API, предоставьте им удобную документацию. Если вы создали JSON-схему, используя prmd , как описано выше, вы можете легко сгенерировать Markdown документацию для всех конечных url, используя команду prmd doc .

    Вдобавок к описанию конечных url, предоставьте обзор API, включая туда следующую информацию:

    • процесс аутентификации – получение и использование пользовательского токена;
    • стабильность API и его версию, а также информацию о том, как выбрать нужную версию API;
    • общие заголовки запросов и ответов;
    • формат выдачи ошибки;
    • примеры использования API с клиентами на разных языках;

    Предоставляйте примеры запросов, которые можно протестировать

    Предоставляйте примеры запросов, которые пользователи могут протестировать. Для тестирования этих запросов пользователь должен выполнить минимум действий:

    Если вы используете prmd для создания документации, то такие примеры будут сгенерированы автоматически для каждого конечного url.

    Опишите стабильность вашего API

    Вы можете описать степень стабильности вашего API или отдельных конечных url при помощи установки флагов prototype / development / production .

    Для получения дополнительной информации, вы можете изучить документ Политика совместимости Heroku API.

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

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL