api

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

Песочница для тестов доступна уже сегодня (API похоже на API получения/отправки SMS), для доступа к продакшену (ватсап называет это «создание business profile») пока что нужно ручное подтверждение от Whatsapp, запросить можно в своей админке Twilio или напрямую у Whatsapp.

Массовые рассылки можно будет делать только после получения явного согласия пользователя (интересно, сработает ли маленькая галочка внизу экрана?) и после апрува шаблона рассылки ватсапом. Сообщение без апрува ватсапа бот имеет право отправить только в течении 24 часов после того, как ему написал пользователь.

Это шок, потому что всю свою историю Whatsapp противился любым «ботам» и «рассылкам» на своей платформе. «Только настоящие сообщения от живых людей».

Насколько это изменение продиктовано заботой о пользователях, а насколько — требованием Facebook поднять прибыли — неизвестно.

В любом случае — медиа это должно быть интересно.

Твиттер представил новое Premium API для поиска. Он позволяет делать достаточно хитрые запросы по твитам за всё время жизни твиттера, но стоит 1$ за запрос (и это не шутка).

Исторически у твиттера было две версии API: бесплатная и enterpise.

Бесплатное API даёт смотреть последние твиты и постить новые.

Вся статистика и нормальный поиск входили в Enterprise API. Годовой контракт - персональный менеджер - стоит как самолет - точная цена по запросу.

В ноябре 2017 они объявили о создании нового тарифа Premium. Он дешевле Enterprise и при этом позволяет делать более сложные поисковые запросы по твитам за последние 30 дней — не особо интересно.

Новый endpoint позволяет искать твитам за всё время. И главное — 50 (пятьдесят, это не опечатка) запросов в месяц бесплатно. Дальше запросы докупаются пачками, пакет в 100 запросов в месяц стоит 99$, с объемом пакетов цена падает, 2500 запросов стоят 1899$.

Всё это производит очень неприятное впечатление. Была норм технологическая компания, а теперь одни сейлзы остались.

Угадайте, кому нужны такие запросы? Мне кажется — следователям, которые хотят нарыть на тебя всё, что ты когда-либо писал. Уверен, что крупные компании делали это с Enterprise API, теперь это могут себе позволить и фрилансеры.

Paw.cloud — самый крутой способ делиться API-запросами в команде. Paw — лучший клиент для тестирования API (только под мак).

Переделываем пуши в Firebase. Нужно сначала написать, а потом протестировать разные запросы. Без Paw это заняло бы гораздо больше времени, чем с ним.

Пример крутой фичи: легко включить бесчеловечную Oauth 2 JWT-авторизацию и добавлять (и обновлять) токен при каждом запросе. А уж версионирование и однокнопочная синхронизация проекта внутри команды — магия.

Paw.cloud стоит 10$ на члена команды в месяц. Одноразовая лицензия на клиент без синхронизации — 50$.

Google обновил в ноябре Firebase Cloud Messaging — одну из самых крутых систем для рассылки пуш-уведомлений в мобильные приложения и браузеры (при этом — бесплатную!).

В новой версии API можно в едином сообщении указать два разных payload; клиент получит свою версию в зависимости от платформы — iOS или Android. Ура! Ложка дёгтя: авторизация теперь богопротивным Oauth2 JWT.

P.S. Документация у Firebase — тихий ужас :(
P.P.S. Никогда не собирайте тестовые приложения с продакшен-ключами. Я сегодня таким макаром отправил в продакшен iOS Медузы тестовый пуш. Слава богу, не в канал «breaking». Слава богу, что тексты тестовых пуши — копии недавних легитимных, а не «тестовый пуш, йоу» или «alert('fuck')». Храни вас бог при тестировании пушей и почтовых рассылок. Аминь.

Хорошая полемическая статья (aka trolling) на на тему «чем плох REST».

1. Переводить сложные операции на язык, в котором всего 4 глагола - то ещё развлечение.
2. В парадигме REST неестественно передавать изменения машины состояний, а это часто необходимо и ошибки на этом фронте могут быть фатальны.
3. Коммуникация ошибок и других особых состояний: «всегда HTTP 200 OK, а ошибка в теле» или придумаем свои коды?

https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d

Мой вывод: парадигмы, правила и концепции - это наши рабочие инструменты. Не человек и дела для инструментов, но наоборот. Каждой задаче - свой инструмент. Черт, кажется это просится в инстаграм глубокомысленные цитаты. Сорян.

Вчера мне пришло удивительное письмо:

Мой друг в составе команды исследователей шельфа северного ледовитого океана сейчас «болтается» в **, чуть западнее острова N на корабле Z. В море им быть ещё минимум два месяца. Говорит, без новостей с большей земли пухнет голова. У них есть интернет, через спутниковый телефон, но канал очень узкий. Если это не сложно для вашего технического отдела, не могли бы организовать отправку дайжеста новостей на электронную почту текстом в архиве на электронную почту xxx@xxx.ru размером письма не более 100 кБ?

Письма Вечерней Медузы за последнюю неделю весят в среднем 50-70KB. Львиная доля объема — код, что позволяет выглядеть письмам одинаково во всех почтовых клиентах; это почище кроссбраузерной верстки.

Давайте попробуем убрать всю красоту и оставим только текст и минимальные выделения. Текст ниже — для компьютерщиков. TL;DR: «вот так, с помощью нехитрых приспособлений...»

Откуда мы будем получать событие об отправке письма? Подойдет webhook в mailchimp, через который мы рассылаем вечерку. Настроим простенькое приложение webhook, которое будет ждать события, а при его получении — запускать нашу программу.

Что в самой программе? Зная ID почтовой рассылки мы можем через API мейлчимпа получить тело письма. Но оно не особо красивое и вычищать его не хочется. Как насчет API Медузы? И вправду, в plaintext версии письма последняя ссылка — всегда на это же письмо на сайте. Например, вот вчерашнее письмо https://meduza.io/brief/2017/09/05/vechernyaya-meduza.

Добавляем `api/v3/` в адрес новости после имени сервера и получаем адрес API https://meduza.io/api/v3/brief/2017/09/05/vechernyaya-meduza. Тут уж есть поля .root.mail.subject и body, которые содержат тему и тело письма, без лишних стилей. Отлично, вычленяем нужные поля с помощью утилиты парсинга json jq и схлопываем их вместе в готовый email.html файл утилитой cat.

Как отправить получившееся письмо? У сервиса отправки писем Amazon Simple Email Service есть отличный SMTP-интерфейс и я как раз недавно нашел программу sendemail (не путать с sendmail, которая позволяет отправлять письма через SMTP из командой строки.

Теперь исследователь севера каждый вечер будет получать «высушенную» версию Вечерней Медузы весом всего 15КБ.

А вы можете подписаться на красивую, сверстанную с любовью Вечерку в почте или в телеграм-канале @meduzaevening и узнавать новостную повестку дня за пару минут.

Пост гордости:

Отдел быстрого повесточного программирования в лице Alexander Polivanov, Alexey Prilepskiy и Виктор Ходак сделал карту протестов. Логарифмическая шкала для цветов, качественные геометки, данные, обновляемые в реальном времени.

Хочу отметить скорость разработки, немыслимую ещё год назад.

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

Спасибо большое ОВД-Инфо за данные, причем в технологичном формате (API), обновляемые в риал-тайме — очень приятный пример сотрудничества.

https://meduza.io/feature/2017/06/07/protestnaya-karta-rossii

У строителей под моим окном классическая «микросервисная архитектура приложения». У них есть 3 сервиса — полый бур, сверлящий дырку в земле, бетономешалка, не дающая бетону застыть и насос, закачивающий бетон из мешалки в отверстие, сверлимое буром.

Красным на картинке отмечены места, в которых один сервис «передает» бетон другому. Там должны быть подходящие отверстия, крепления и допустимое предельное давление бетона (чтобы это всё не разорвало) — это API. API — договоренности, по которым сервисы общаются друг с другом.

Допустим, можно было бы сделать убер-машину, которая умеет все — сверлить, качать и мешать. Засыпаете бетон, вставляете сверла и она делает вам готовые заполненные бетоном дырки — это была бы «монолитная архитектура приложений». Её было бы сложнее транспортировать по улицам и, наверное, ей нужен был бы очень крутой инженер для обслуживания.

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