Исследователи из OpenAI показали алгоритм GPT-3, предназначенный для написания текстов на основе всего нескольких примеров. Его архитектура Transformer аналогична GPT-2, но модель обучали на 175 миллиардов параметров или 570 гигабайтах текста.

^{В блоге GitHub, вышла новость о презентации описания GitHub OpenAPI. Предлагаем вам ознакомиться с ее переводом на русский. Оригинал новости можно увидеть по ссылке.}

С момента его первого выхода GitHub REST API был выпущен в трёх основных редакциях. И это всего через месяц после запуска сайта. Мы часто получаем отзывы о том, что наш REST API вдохновляет в архитектуре, и что он является отраслевым справочником того, как вообще должен выглядеть API. Сегодня мы рады объявить об улучшении способов взаимодействия разработчиков с нашим API. Доступен исходный код описания REST API средствами OpenAPI.

Где то полгода назад я сильно увлекся OpenID и всем что с ним связанно. Моим главным занятием в это время стало — неспешное чтение спецификаций, форумов, блогов и хабрапостов OpenID тематики.

Все знания, которые мной были получены за это время, я «материализовал» в проекте компании, в которой собственно я работаю.

Изучая спецификацию OpenID и прочих его расширениях (SREG, AX) и надстройках, мне пришла идея разработать JavaScript виджет со своим API-прослойкой, в помощь другим разработчикам нежелающим «коротать» дни и ночи изучая спеки различных способов авторизации и их расширений.

Собственно об этом далее.

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

Облегчало реализацию два факта: первый заключается в том, что Open API мне очень напоминал Facebook Connect, с которым я уже работал. Второй факт был ещё весомей — у меня уже есть библиотека в которой каждый вариант авторизации (OpenID, OAuth, FacebookConnect) являются отдельными бэкендами и написать дополнительный, тем более так похожий на FC не выглядело сложным заданием. В итоге, можно сказать что по факту это действительно оказалось плёвым делом.

Итак, что же нужно для авторизации по Вконтакте.ру?

Сколько процентов пользователей вашего сайта являются также пользователями ВКонтакте? Как по вашему, сколько человек ничего не пишут / комментируют / добавляют (нужное подчеркнуть), лишь потому, что им лень регистрироваться на еще одном непонятном сайте в 100й раз? Предлагаю ответить для себя на эти 2 вопроса, прежде, чем ругать ВКонтакте и Open API.

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

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

В недавнем моем посте «Javascript виджет авторизации OpenID» на хабре, я описал свою разработку виджет-consumer авторизации OpenID.

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

С момента анонса и запуска проекта Loginza нашей компанией в массы, прошло уже 3 месяца. За это время было проделано много работы: была проведена оптимизация скорости загрузки и работы виджета, небольшие косметические правки, но и так же мы расширили список поддерживаемых в виджете провайдеров авторизации.

В виджет добавились такие монстры как Вконтакте, Facebook, Twitter и Last.fm. Партнерство с mail.ru помогло нам сделать интеграцию с api.mail.ru более гибкой и с большим набором данных профиля, чем прежняя авторизация через openid.mail.ru.

Но самое главное, это пополнение ряда плагинов для таких CMS как Joomla, vBulletin, Drupal, блог движка Wordpress, движка интернет магазинов PrestaShop, но и для популярного форумного движка phpBB. Собственно о нем и речь.

Кто хоть раз тестировал свой WebAPI знает такие инструемнты, как Postman или Advanced REST (экстеншены для Chrome). Эти инструемнты всем удобны, кроме того, что не умеют сами узнавать какие модели принимает API, какие отдает и не предоставляет информацию обо всех возможных эндпоинтах. Это неудобство решает пакет Swashbuckle, который встраивает в проект генерацию Swagger спецификации и UI. Под катом коротко о том, как его прикрутить к проекту и некоторые детали относительно авторизации и работы с «перегруженными» эндпоинтами.

Всем привет! Все началось с интеграции телефонной платформы в корпоративный сайт.

WEB-разработка поразила разнообразием подходов и методов реализации. Стек технологий пестрит разнообразием, выбор инструментов определяет стиль разработки, модульность или закостенелость проекта.

Про телефонную платформу я напишу в следующий раз. Сильный уклон в VoIP-специфику отвлечет от главного — методов разработки современного SPA-приложения.

В статье будет описан процесс внедрения стороннего сервиса в существующую рабочую среду.

Сегодня поиграемся с Zabbix-API.

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

Ключевые слова для оценки полезности: API, REST, OpenAPI, Swagger, рефакторинг взаимодействия систем.

Привет, %username%!

Ты наверняка знаешь, что такое API интерфейсы и то, как много от них зависит в твоем проекте. Более того, я так же полагаю, что ты уже знаком с тем, что такое API first подход и знаешь, что Swagger и его Open API являются одними из самых популярных инструментов, помогающих ему следовать.

Но в этой статье я хочу рассказать про подход к реализации API first, концептуально отличающийся от того, что предлагает Swagger и Apiary. Во главе идеи стоит понятие Single contract и возможность его реализации на базе RAML 1.0.

Под катом:

• Краткое описание принципов API first;
• Single contract – ввод понятия, предпосылки к появлению, рассмотрение возможности его реализации на базе OAS (Swagger);
• RAML + annotations + overlays как база для Single contract, примеры;
• Проблемы RAML, концептуальные разногласия разработчиков;
• Идея SaaS сервиса на базе вышеизложенной идеи (картинка прототипа сверху).

В этой статье речь пойдёт о написании и поддержке полезной и актуальной спецификации для REST API-проекта, которая позволит сэкономить много лишнего кода, а также серьёзно улучшить целостность, надежность и прозрачность прокта в целом.

Что такое RESTful API?

Это миф.

Серьёзно, если вы думаете, что в вашем проекте RESTful API, вы почти наверняка ошибаетесь. Идея RESTful — в построении API, который во всём соответствовал бы архитектурным правилам и ограничениям, описанным стилем REST, однако в реальных условиях это оказывается почти невозможно.

В рамках профессиональной деятельности разработчикам, пентестерам, безопасникам приходится сталкиваться с такими процессами, как Vulnerability Management (VM), (Secure) SDLC.
Под этими словосочетаниями скрываются различные наборы практик и используемых инструментов, которые переплетены между собой, хотя их потребители различаются.

Технический прогресс пока не дошёл до того, чтобы одним инструментом заменить человека для проведения анализа защищённости инфраструктуры и ПО.
Интересно понять, почему это так, и с какими проблемами приходится сталкиваться.

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

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

Наверняка при разработке API не раз появлялись сложности с документацией: то её нет, то она не отображает поведение, описанное в коде.

С точки зрения разработчика, написание документации (одной только внутренней) занимает не меньше времени, чем написание самого кода. Знакомо? Тогда добро пожаловать под кат.

Фото Chris Keats на Unsplash

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

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

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

Лого взято из Github репозитория FastAPI

FastAPI — относительно новый веб-фреймворк, написанный на языке программирования Python для создания REST (а если сильно постараться то и GraphQL) API, основанный на новых возможностях Python 3.6+, таких как: подсказки типов (type-hints), нативная асинхронность (asyncio). Помимо всего прочего, FastAPI плотно интегрируется с OpenAPI-schema и автоматически генерирует документацию для вашего API посредством Swagger и ReDoc

FastAPI построен на базе Starlette и Pydantic.
Starlette — ASGI микро-фреймворк для написания веб-приложений.
Pydantic — библиотека для парсинга и валидации данных основанная на Python type-hints.

Два года назад я начал разработку еще одного свободного кодогенератора из OpenAPI Specification v3 в TypeScript (он доступен на Github). Изначально, я задался целью сделать эффективную генерацию примитивных и сложных типов данных в TypeScript, с учетом различных возможностей JSON Schema, таких как oneOf/anyOf/allOf и т.п. (у родного решения от Swagger с этим были некоторые проблемы). Другая идея заключалась в том, чтобы использовать схемы из спецификаций для валидации на фронте, бэке и в других частях системы.

Хорошая спецификация к API помогает клиентам его использовать. Несколько месяцев назад на большом Pytup разработчик Яндекса Александр Брязгин bryazginnn выступил с докладом о том, что собой представляет спецификация REST API на примере OpenAPI + Swagger и зачем нужна такая связка. Из конспекта можно узнать, как мы прикручивали автоматическую генерацию спецификации в уже готовом сервисе, какие библиотеки нам пригодились и какой есть тулинг вокруг спецификации OpenAPI.


— Всем привет, меня зовут Александр. Я хотел бы поговорить с вами про спецификации.

• ваша система состоит из множества взаимосвязанных сервисов?
• всё ещё вручную актуализируете код сервисов при изменении публичного API?
• изменения в ваших сервисах часто подрывают работу других, а другие разработчики вас за это ненавидят?

Если ответили да хотя бы один раз, то добро пожаловать!