Интро
Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.
В тексте попадаются комментарии переводчика, они выделены курсивом.
Собираем API-интерфейсы, которые понравятся другим разработчикам
Понятные URL для вызовов API
Первый принцип хорошего REST-дизайна — делать
вещи понято и просто. Начинать стоит с основных URL адресов для ваших вызовов API.
Ваши адреса вызовов должны быть понятными даже без документации. Для этого возьмите себе за правило описывать любую сущность с помощью коротких и ясных базовых URL адресов, содержащих максимум 2 параметра. Вот отличный пример:
/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой
Существительные — это хорошо, а глаголы — плохо
Держите глаголы как можно дальше от базовых URL сущностей вашего API. Многие разработчки используют глаголы для описания объектов. Ясное дело, что в работе часто приходится моделировать сложные сущности. И эти сущности взаимодействуют между собой. Но при попытке ввести глаголы для моделирования сущностей и их связей, мы, скорее всего, получим большое количество труднозапоминаемых и непонятных вызовов:
/getAllDogs
/getAllLeashedDogs
/getDog
/newDog
/saveDog
Видите эти вызовы? Это ужас.
Вместо глаголов — HTTP
Мы только что описали собак с помощью двух базовых URL адресов с существительными. Теперь нам нужно работать с созданными сущностями. Чаще всего требуются операции чтения, создания, редактирования и удаления (CRUD — Create — Read — Update — Delete). Для этого нам прекрасно подойдут HTTP-методы
GET,
POST,
PUT и
DELETE.
POST /dogs — создать новую собаку
GET /dogs — получить список собак
PUT /dogs — редактирование всех собак сразу
DELETE /dogs — удаление всех собак
POST /dogs/12345 — вернуть ошибку (собака 12345 уже создана)
GET /dogs/12345 — показать информацию о собаке
PUT /dogs/12345 — редактировать собаку 12345
DELETE /dogs/12345 — удалить
Базовые URL выглядят просто, глаголы не используются, все интуитивно и понятно. Красота!
Множественное число
Хорошо использовать для описания бызовых URL существительные во множественном числе. Хуже — в единственном числе. Плохо — смешивать адреса с существительными в единственном и множественном числе.
/checkins у Foursquare
/deals y GroupOn
/Product y Zappos
Конкретные имена лучше абстрактных
Абстрактные названия — это часто считается крутым у архитекторов API. И это совсем не круто для тех, кто потом с этим API будет работать.
/blogs, /videos, /news, /articels — это выглядит очевидным. А вот /items и /assets — нет.
Связи
Одни ресурсы всегдя связаны с другими ресурсами. Если ли очевидный и простой способ показать эти связи через API. При этом помня о нашем разделении на существительные и глаголы?
GET /owners/5678/dogs
POST /owners/5678/dogs
Мы только что представили связь двух ресурсов в простом виде. Метод GET в этом случае вернет нам список собак владельца 5678, а метод POST — добавит владельцу 5678 еще одну собаку.
Связи очень удобно представлять в виде
/ресурс/идентификатор/ресурс.
Сложные вещи нужно прятать за знаком «?»
Почти у каждого API есть куча параметров, которые можно читать, обновлять, фильтровать и работать с ними всякими другими способами. Но все эти параметры не должны быть видны в базовых адресах. Лучше всего указывать параметры внутри обращения к базовым адресам.
GET /dogs?color=red&state=running&location=park
А что насчет ошибок?
Хороший механизм обработки ошибок — это часть любого хорошего API. Давайте посмотрим, как выглядят ошики в популярных API.
Facebook
HTTP Status Code: 200
{"type" : "OauthException", "message":"(#803) Some of the aliases you requested do not exist: foo.bar"}
Не важно, как выполнится запрос — Facebook всегда вернет нам код 200 OK.
Twilio
HTTP Status Code: 401
{"status" : "401", "message":"Authenticate","code": 20003, "more info": "http://www.twilio.com/docs/errors/20003"}
Twilio проделали хорошую работу и для каждой ошибки в API подобрали адекватный код ошибки HTTP. Как и Facebook, ребята предоставляют информацию об ошибке еще и в теле ответа. И, что самое прикольное, они дают ссылку на документацию по проблеме.
SimpleGeo
HTTP Status Code: 401
{"code" : 401, "message": "Authentication Required"}
SimpleGeo дают сообщение об ошибке в коде HTTP и снабжают его небольшим пояснением в теле ответа.
Используйте коды ответов HTTP
Смело берите HTTP коды ответов и сопоставляйте с ответами вашего API. Всего в частом употреблении находится около 70-ти кодов. Мало кто из разработчиков помнит их все, так что из этих 70-ти лучше взять примерно 10. Кстати, так поступает большая часть провайдеров API.
Google GData
200 201 304 400 401 403 404 409 410 500
Netflix
200 201 304 400 401 403 404 412 500
Digg
200 400 401 403 404 410 500 503
Какие коды ошибок HTTP стоит использовать?
Возможно только 3 варианта ответов API
- Запрос прошел успешно
- На вход были переданы неправильные данные — клиентская ошибка
- Произошла ошибка при обработке данных — серверная ошибка
Так что можно взять за основу 3 кода ответов:
- 200 OK
- 400 Bad Request (некорректный запрос)
- 500 Internal server error (внутренняя ошибка сервера)
Если 3-х кодов вам недостаточно — возьмите еще 5:
- 201 Created (Запись создана)
- 304 Not Modified (Данные не изменились)
- 404 Not Found (Данные не найдены)
- 401 Unauthorized (Неаторизованный доступ)
- 403 Forbidden (Доступ запрещен)
Лучше всего не следовать этой практике слепо. Оценивайте пользу от использования HTTP кодов ответов
в каждом конкретном случае. Скорее всего, использование кодов ответов не везде будет оправданным и уместным. Например, если вы пишете бэкенд для небольшого веб-приложения — то легко можно ограничиться кодами ошибок в теле ответа. А еще стандартый ответ 200 OK позволит создать два механимза обработки ошибок: для ошибок сервера и для ошибок самого API. В общем — думайте, взвешивайте. А потом принимайте решение.И, конечно же, при ошибке всегда нужно прикладывать сообщение для разработчиков. А приложить к сообщению ссылку на документацию по проблеме — это еще лучше.
Никогда не выпускайте API без указания версии
Twilio /2010-04-01/Accounts
salesforce.com /services/data/v20.0/sobjects/Account
Facebook ?v=1.0
Twilio требует при каждом запросе к API передавать время, когда приложение разработчика было скомпилировано. На основе этой даты Twilio определяет, какую версию API нужно предоставить приложению. Это умный и интересный подход, но слишком сложный. А еще можно легко запутаться с датами.
Salesforce.com вставляет v20.0 в середину адреса API запроса. И это очень хороший подход. Но не стоит использовать точку в нумерации версии — это провоцирует излишне частые изменения в интерфейсе API. Можно сколь угодно часто менять логику работы внутри API, но вот сами интерфейсы должны меняться максимально редко. Так что лучше обойтись без точки и не искушать себя.
Facebook тоже использует нумерацию версий в запросе, но прячет её в параметры запроса. И этот подход плох тем, что после очередного внедрения новой версии API все приложения, не передающие версию в запросе, начинают глючить.
Как реализовать версии в API?
Используйте префикс v, целые числа и располагайте номер версии в левой части адреса. Например, /v1/dogs.
Держите в рабочем виде как минимум одну предыдущую версию
Еще можно указывать версию в заголовках ответа сервера. Это может давать некоторые дополнительные возможности при работе с API. Но если вы используете множество разных версий и требуете обязательно указывать их в заголовках — это симптом большой проблемы.
Частичный ответ
Частичный ответ позволяет разработчикам запросить только ту информацию, которая им нужна. Например, запросы к некоторым API могут вернуть кучу лишней информации, которая почти не используется: всякие таймстампы, метаданные и т.д. Чтобы не запрашивать лишнюю информацию, в Google придумали чистичный ответ.
Linkedin /people: (id, first-name, last-name, industry)
Facebook /joe.smith/friends?fields=id,name,picture
Google ?fields=title, media:group(media:thumbnail)
Перечислять необходимые поля через запятую в адресе запроса — это очень простой и удобный подход. Берите его на вооружение.
Сделайте простую паджинацию
Отдавать все записи по первому же запросу — очень плохая идея. Поэтому вы должны обязательно предусмотреть паджинацию. Давайте посмотрим, как в популярных API можно вытащить записи с 50 по 75.
Facebook: смещение 50 и лимит 25
Twitter: страница 3 и 25 записей на страницу
Linkedin: с 50-й записи прочитать 25
Мы рекомендуем использовать лимит и смещение. Этот подход более интуитивен.
/dogs?limit=25&offset=50
Еще стоит приложить к каждому ответу мета-информацию: текущая страница, сколько всего записей доступно.
Предусмотрите значения по умолчанию: если пользователь не передал в запросе параметры паджинации, считайте лимит равным 10 и смещение — равным 0 (вывести первые 10 записей).
А что насчет действий?
Не все API-ресуры являются записями, которые можно читать, редактировать и удалять. Бывают и API-действия. Переводы, вычисления, конвертации — все это действия.
Лучше всего для таких запросов использовать глаголы, а не существительные.
/convert?from=EUR&to=USD&amount=100
Убедитесь, что даже просто глядя на список вызовов в документации можно отличить сущности от действий.
Поддержка нескольких форматов
Здорово поддерживать несколько форматов ответа.
Google ?alt=json
Foursquare /venue.json
Digg ?type=json
Кстати, Digg позволяет установить формат ответа и через HTTP-заголовок Accept.
Мы рекомендуем подход Foursquare.
/dogs.json
/dogs/1234.json
Еще можно предусмотреть ответы API не только в разных форматах, но и ответы для разных типов клиентов. Например, можно сделать API, способное работать одновременно с iOS-приложением и фронт-эндом веб-приложения. Это может выглядеть так: /dogs.ios и /dogs.web.Формат по умолчанию
JSON — пожалуй, лучший формат по умолчанию. Он менее многословен, чем XML. Его поддерживают все популярные языки. Его можно сразу же использовать на фронт-энде веб-приложения.
Названия атрибутов
Атрибуты можно называть разными способами.
Twitter created_at
Bing DateTime
Foursquare createdAt
Существует много конвенций именования переменных. Нам, как спецам по Ruby on Rails, конвенция Twitter близка по духу. Но лучшим подходом мы считаем подход Foursquare: — camelCase (переменные с маленькой буквы, классы — с большой). Такой способ именования наиболее симпатичен для подачи данных в JSON: данные выглядят похоже на JavaScript. Что, в общем, логично для JSON.
Хоть автор и советует почаще использовать camelCase, лучше все же подумать о клиенте и потом уже принимать решение. Например, с вашим API может общаться программа, написанная на C, а ей лучше использовать несколько_другую_конвенцию.
Поиск
Глобальный поиск оформить просто:
/search?q=search+word
Поиск по конкретным сущностям можно легко представить, опираясь на то, что мы узнали ранее:
/owners/5678/dogs?q=red
А чтобы представлять данные в разных форматах, мы вспомним о расширениях:
/search.xml?q=search+word
Соберите все API вызовы на одном домене
Facebook предоставляет два домена.
api.facebook.com этот адрес появился первым
graph.facebook.com этот адрес ввели после внедрения глобального графа
Foursquare ограничились одним адресом
api.foursquare.com
Twitter завели 3 адреса, 2 из которых ориентированы на посты и поиск
stream.twitter.com
api.twitter.com
search.twitter.com
Легко догадаться, как Facebook и Twitter завели себе по несколько адресов: проще направлять запросы в разные кластеры через DNS, чем через логику. Но мы делаем приятный API для разработчиков, поэтому опять выберем подход Foursquare.
На всякий случай напомню, что разработчикам небольшого бэкенда для веб-приложения не надо выделять отдельный домен, чтобы не создавать проблемы с кроссдоменными ajax-запросами на фронт-энде.
Делайте редиректы
Если кто-то обращается к вашему API-домену и не передает никаких параметров — смело делайте редирект на домен с документацией для разработчиков. Заведите несколько интуитивно понятных доменов для документации и делайте редирект на основной домен разработчиков.
api.* -> developers.*
dev.* -> developers.*
developer.* -> developers.*
Коды HTTP ответов и исключения на клиенте
Как мы уже говорили ранее, лучше всего отправлять код ошибки не только в теле ответа API, но и в HTTP коде ответа. Но как быть, если клиент выбрасывает исключение при получении любого кода HTTP, отличного от 200? Для таких случаев ребята из Twitter предусмотрели блестящее и простое решение — добавлять параметр к запросу.
/public_timelines.json?suppress_response_code=true
В результате ошибки будут приходить с кодом 200.
Предусмотрите в своем API параметр
suppress_response_codes и сделайте его равным
true по умолчанию.
А что если клиент поддерживает ограниченный набор HTTP методов?
В таком случае нужно эмулировать полноценный REST API с помощью GET-параметров.
чтение /dogs
создание /dogs?method=post
редактирование /dogs/1234?method=put
удаление /dogs/1234?method=delete
Будьте аккуратны с таким подходом! Если вы будете неаккуратно обращаться с такими ссылками и не обеспечите им должной безопасности, боты (вроде поискового робота Google) могут вызывать такие ссылки. И вы получите бесконечно создающиеся и удаляющиеся записи при каждом заходе бота.
Авторизация
Этот вопрос сложный, и мы с моими коллегами никогда не можем прийти к согласию быстро. Давайте посмотрим, что делают ведущие игроки.
PayPal Permissions Service API
Facebook OAuth 2.0
Twitter 1.0a
Обратите внимание на то, что PayPal реализовали свою систему авторизации еще до того, как был изобретен OAuth.
Если вам требуется авторизация пользователей через сторонние приложения — только OAuth. И ни в коем случае не делайте что-то вроде OAuth, но «немного другое».
«Болтливые» API
«Болтливые» — это значит, что для выполнения популярных операций приходится выполнять 3-4 вызовоа API подряд. Это плохо.
Попробуйте посмотреть на ваши вызовы глазами пользователя. Вы увидите, что примерно 80% вызовов принимают и отдают данные одинаковой структуры. Это значит, что вполне можно сделать псевдонимы для последовательностей вызовов. После этого пользователь сможет единожды направить данные на вход, и вся цепочка вызовов выполнится сама.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html
Когда The Guardian