REST API, несколько историй

Добрый вечер, читатели!
Так уж сложилось, что публично я пишу API integration, да и не публично тоже, хотя в рабочей жизни это наиболее редкое мое занятие. И захотелось мне высказаться на примере четырех сервисов обертки над АПИ которых есть у меня в профиле github.

И так, хорошие примеры, это биткоин биржи cex.io(ставлю оценку 5 за реализацию API) и btc-e (оценка 5 с минусом)
Плюсы:

• HTTPS соединение
• Подпись каждого запроса сигнатурой на базе nonce, секретного ключа, ключа апи и hmac sha256512
• Интуитивно понятные url
• Адекватное использование POST параметров
• Ответы в JSON, что сейчас не только стандарт де-факто, но и просто признак хорошего тона
• Простота в строении

Минусы:

• Ограничение в количестве запросов на единицу времени, хотя, это не относиться к API, привет CloudFlare

Немного остановлюсь и расскажу, про то, что в обоих случаях бОльшую часть времени отнимало создание функций создания сигнатур и базовой (в моем случае) функции api_call, все остальные функции — глупые обертки над api_call. Отдельно хочу выделить cex.io в методе получения тикеров (текущих цен), историй ордеров — все это построено по тому же принципу, что и остальные методы, никакого геморроя.
В противовес им выступает 2ой образец хорошего API — btc-e. Пока нам не надо получать информацию по тикерам, ордерам и комиссиям все идеально. Но, если мы желаем получить данную информацию, нам надо… получать её GET запросами с других адресов довольно таки слабо связанных с основным API

Теперь перейдем к нашему третьему пациенту — unisender (моя оценка API — 3)
Плюсы:

• Ответы в JSON
  Больше плюсов я не нашел, перейдем к минусам:
  • Безопасность «ниже плинтуса»
  • Без чтения дока по апи понятно не будет ничего, точнее почти ничего
  • Слишком много всего в одном методе
  • Как-то странно смотрится вместе с предыдущим пунктом, но слишком много методов на выполнение одного действия
  • Общая монстроузорность

  Снова остановлюсь. Я не буду говорить про безопасность и понятность API, а приведу пару примеров по трем последним пунктам. Почему бы не добавить в метод создания сообщения флаг автоматической отправки? Но нет, мы должны сначала создать сообщение, а потом его отправить. Хотя, подождите, у них же есть метод sendEmail, казалось бы то, что нужно, однако при внимательно рассмотрении мы видим, что в этом методе не один метод, а целых два, один срабатывает если отправить все данные строками, тогда произойдет рассылка одинаковых сообщений на указанную почтусписок, а вот если мы передадим данные массивами, то для каждому адресату будет отправлено свое сообщение. Зачем? Зачем, когда проще будет вызвать несколько раз метод, действительно проще.
  Ну ладно, это была троечка, перейдем к аутсайдеру imobis (оценка — 2)
  Плюсы: не обнаружено
  Минусы:

  • XML! Все в xml и ответы и запросы
  • Парсер xml — кривой, ребят, вы серьезно считает, что если между тэгами стоит CDATA, то пробелы и переносы строк относятся к CDATA?
  • Полное отсутствие логики в URL
  • Безопасность, логин и пароль — открытым текстом, POST, а то и GET запросом, голым HTTP!!!

  Даже комментировать не буду

Автор: t0pep0

Источник ^[1]