company_banner

API Я.ру (бета)

  • Из RSS
Внимание: пост для разработчиков! Представители других профессий могут быть несовместимы с текстом и проявлять при прочтении поведенческие признаки скуки.
Мы — разработчики Яндекса — внимательно слушаем, о чём нас просят пользователи, а также другие разработчики. Конечно, мы не всесильны и не можем обеспечить счастья сразу всем, но нам очень приятно, когда получается сделать что-то хорошее. Вот как сегодня. Мы открываем в публичное бета-тестирование не один, а сразу два сервиса:
  • API для нашего любимого блогохостинга — Я.ру.
  • сервис OAuth-авторизации для этого и других наших API
Разрабатывая их, мы не только придерживались принципов открытости и соответствия стандартам, но и дали себе волю заметно поднять «градус гиковости» — API строится на самых модных технологических принципах.

Авторизация — это начало работы с API, с неё и начнём. В качестве стандарта мы выбрали OAuth 2.0. Несмотря на то, что он пока только черновик, мы решили реализовать его по очень простой причине — это открытый стандарт, который собираются поддерживать самые развитые технологические компании мира. Его предыдущие версии реализованы, например, в Google и Twitter. Мы надеемся в будущем поддержать этот вид авторизации в других наших API, например — в Фотках (да-да, мы слышали, что вы жаловались на их сложную авторизацию!)

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

Структурно API построено по идеологии REST:
  • весь сервис представлен в виде ресурсов, имеющих состояние
  • каждый ресурс имеет стандартный интерфейс доступа, основанный на методах и кодах ошибок HTTP
  • ресурсы используют URI для навигации по связанным частям системы
  • где можно, используются стандартные форматы представления данных и протоколы — в частности, Atom и AtomPub
Мы выбрали REST, потому что он максимально отражает наши взгляды на то, каким должен быть API веб-сервиса. Стандартизованный интерфейс и открытые форматы дают разработчикам возможность использовать свои наработки и сторонние библиотеки для разных сервисов, вместо того, чтобы писать абсолютно уникальный код для каждого. Со стороны же сервиса это сильно упрощает поддержку документации, а также, например, даёт возможность более удобно масштабировать сервисы и сочетать их друг с другом.

Это может показаться довольно сложным, поэтому, чтобы дать почувствовать, что на практике всё сильно проще, вот короткий пример кода на Питоне, который меняет настроение пользователя:

# -*- coding:utf-8 -*-
from urllib2 import urlopen, Request

import elementflow
import lxml.etree


ACCESS_TOKEN = 'f46606d61b9249078945599fb7192eb2'
NAMESPACES = {
  '': 'http://www.w3.org/2005/Atom',
  'y': 'yandex:data',
}
HOST = 'api-yaru.yandex.ru'


def auth_request(url, body=None):
    '''Создаёт авторизованный объект запроса.'''
    return urlopen(Request(url, data=body, headers={
        'Authorization': 'OAuth %s' % ACCESS_TOKEN
    }))

def get_link(rel):
    '''Возвращает URL нужного ресурса из профиля авторизованного пользователя.'''
    f = auth_request('https://%s/me/' % HOST)
    xml = lxml.etree.parse(f)
    namespaces = {'y': NAMESPACES['y']}
    links = xml.xpath('/y:person/y:link[@rel="%s"]' % rel, namespaces=namespaces)
    return links[0].attrib['href']

def change_mood(mood):
    '''Создаёт пост типа "смена настроения".'''
    with elementflow.xml(elementflow.Queue(), 'entry', namespaces=NAMESPACES) as xml:
        xml.element('category', {'scheme': 'urn:wow.ya.ru:posttypes', 'term': 'status'})
        xml.element('content', text=mood)
        xml.element('y:comments-disabled')
    auth_request(get_link('posts'), xml.file.pop())


if __name__ == '__main__':
    change_mood(u'Тестовое настроение')

Подробнее — в документации.

Выпуская API не в виде законченного сервиса, а бета-версией, мы приглашаем тестировать его всех заинтересованных разработчиков. Нам интересно получить от вас пожелания по функционалу и сообщения об ошибках, пишите в Клуб сервиса Я.ру. И API, и протокол OAuth, который тоже находится в стадии черновика, обязательно будут меняться, будьте к этому готовы.
За дело!

Иван Сагалаев и Григорий Бакунов, гики со стажем
.

Яндекс

470,00

Как мы делаем Яндекс

Поделиться публикацией
Комментарии 39
    –28
    Мда…
      +1
      хабру бы еще такое апи. мы бы тогда в свой блог — клиент для мобильного добавили.
        0
        Скажите, авторизация OAuth работает для почтового API?
          –3
          Хм… Несомненно, с точки зрения красивости, ваша схема отлична. Но с точки зрения готовых библиотек, через XML-RPC или WSDL было бы проще… А тут придется велосипедировать, что не совсем приятно :-(

          Ждем тогда официальную либу для этих сервисов для разных языков, как это делает гугль.
            +4
            > Хм… Несомненно, с точки зрения красивости, ваша схема отлична. Но с точки зрения готовых библиотек, через XML-RPC или WSDL было бы проще…

            Использование WSDL сильно ограничило бы число клиентских платформ, поэтому это вообще не вариант. Что касается XML-RPC и REST, то поскольку они совершенно противоположны по идеологии, простота сильно зависит от того, откуда вы смотрите и какие у вас привычки. По мне, так совершенно идентичный подход REST к семантике редактирования и удаления, самоописывающиеся документы и прочие идеологические вкусности — это большой плюс.

            > Ждем тогда официальную либу для этих сервисов для разных языков, как это делает гугль.

            С либой всегда проще, да. Хотя я пока жду, что кто-нибудь напишет её быстрее нас :-).
              0
              Тоесть SOAP ограничил бы клиентские платформы?

              WSDL — Всего лишь описания сервиса ввиде xml.
              Но вам там виднее конечно. SOA наверно уже перестал рулить…
                +1
                > SOA наверно уже перестал рулить…

                Опять-таки, в зависимости от перспективы, он никогда и не начинал рулить :-). Чтобы не повторяться: softwaremaniacs.org/blog/2008/11/02/rest-vs-ws/
                  0
                  Если честно не оч хочется начинать холивар:)
                  Вот как кстати мог выглядить ваш код на soa, там правда пример с гуглом:)
                  diveintopython.org/soap_web_services/
                    0
                    Понятно, что все это ограничено привычками. Но XML-RPC применяется в Google (Blogspot), LJ, Wordpress и других более мелких платформах. Ваша технология ничуть не хуже (я ниразу не сказал, что она хуже!), но под нее надо писать с нуля новый велосипед, поддерживать его и следить за вашими обновлениями.

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

                    И даже если эти либы и будут, то создателям мультиплатформенных блог-клиентов (поддерживающих не только яндекс), придется вводить вместо простого свича нужного класса подключения (т.к. XML-RPC интерфейсы, скажем, у гугля и вордпресса — идентичны) — новый уровень абстракции, который бы позволял объединить в одной программе слона и носорога.

                    А теперь, объясните мне, зачем? Чтобы покрасоваться как замечательно и весело вы сделали?..
                      –1
                      И даже если эти либы и будут, то создателям мультиплатформенных блог-клиентов (поддерживающих не только яндекс), придется вводить вместо простого свича нужного класса подключения (т.к. XML-RPC интерфейсы, скажем, у гугля и вордпресса — идентичны) — новый уровень абстракции,


                      хм. а какие фичи должен уметь «правильно» абстрагировнный транспортный класс для блогодвижков? есть у меня подозрение, что такой класс почти идеально ляжет на REST. поэтому, подключить ярушный транспорт при правильно написанном клиенте — не проблема.
                        0
                        Почитайте про SOAP, как он создавался и какие корпорации за ним стоят. Это открытый стандарт для общения программ между собой. Вместо того, чтоб потключить Я.сервис и вызвать метод «proxy.ChangeMyStatus(»Я.ру рулит и бибикает");"
                        Я должен парсит непонятную схему xml

                        Я не говорю, что они сделали не правильно, они сделали по гиковски для гиков.
                        Амазон, гугл и прочие вендоры предпочитают SOAP.
                          –1
                          я знаю что такое соап. То что они сделали — в тренде, жуткие многословные монструозные поделки давние потихоньку отмирают. И яндекс, твиттер и другие делают новый мейнстрим. Эволюция.
                            –1
                            я имею в виду ту область, в которой они работают.
                            +1
                            Простите, это просто неправда. Amazon и Google — как раз одни из самых больших пропонентов REST-протоколов. Google Data — это REST'овый AtomPub, а Amazon S3 — хрестоматийный пример REST-сервиса, про который в книжках пишут.

                            Кстати, от SOAP-интерфейс к поиску Google отказался (http://code.google.com/apis/soapsearch/). Просто потому что на практике он не «рулит» и не «бибикает».

                            Вообще, то, что вы просите — это не SOAP, а просто более высокоуровневая библиотека. Повторюсь, она скорее всего напишется под ваш любимый язык, если мы правильно будем продвигать дальше платформу.
                              –2
                              ebogdanov.habrahabr.ru/blog/66729/ впечатление от нового api Gsearch
                              цитата из фака — Amazon S3 provides simple, standards-based REST and SOAP web services interfaces that are designed to work with any Internet-development toolkit.

                              Вообщем -то это извечная война соапщиков и рестоманов.
                              Нынешний soap можно сделать с закосом под рест, в браузере по url'ам будет выдоватся xml и т.д.

                              Конечно rest хорош тем, что кроме библиотеки http вам больше ничего не нужно(ну ещё xml )
                              А для soap не во всех языках есть библиотеки или если есть то не поддерживается последний стандарт.
                              Мне просто сама идея soap нравится.
                                0
                                > Конечно rest хорош тем, что кроме библиотеки http вам больше ничего не нужно(ну ещё xml)

                                Здесь сразу два заблуждения. Во-первых, REST вообще никак не связан с XML. Во-вторых, с протоколом не предполагается работать напрямую, предполагается использовать библиотеки. Основная ценность REST'а проявляется в реализации на серверной стороне и в реализации библиотек, а не для конечных пользователей, которым, по идее, должно быть всё равно.
                                  0
                                  Ладно, вы просто вырываете фразы из контекста.
                                  Началось всё с того, что вы сказали что «Использование WSDL сильно ограничило бы число клиентских платформ, поэтому это вообще не вариант»

                                  Поэтому и такая истерия с моей стороны ибо это не правда и сам soap создавался для того, что независимо от платформы и языка программы могли общатся.

                                  Понятно что rest незавязан на xml, вы можете отдать разные заголовки, но в основном отдают xml.

                                  Возмём за пример твитер, как парсили xml так и парсят дальше.

                                  По сути вы взяди я.ру и вместо html, по другому адресу начали тоже самое отдавать в xml(+ свои супер заголовки).
                                0
                                Насчёт гугла извиняюсь их сервисы действительно завязаны на rest и свой Gdata.

                                en.wikipedia.org/wiki/Web_Services_Interoperability — тут можно посмотреть и почитать про организацию WS-I и кто в неё входит, которая продвигает открытые стандарты soap.

                                А то, что я написал это как раз таки soap(soa).
                                Зачем мне очередная библиотека когда есть открытые стандарты и протокол по которому ваш сервер(не важно на какой платформе) и наши программы(на любом языке) могут обменивается данными?

                                Судя по оценкам Soa людей не впечатляет, ну и ладно…
                            0
                            XML-RPC — это не протокол блог-платформы, а протокол вызова функций на другой машине. Он не предполагает какого-то конкретного API. Поэтому говорить, что используя XML-RPC можно получить универсального клиент для всех блог-платформ, неверно. XML-RPC тут помогает не больше, чем если бы все перечисленные вами платформы были написаны на одном языке программирования. С клиентской стороны это незначительная реализация.

                            Чтобы сделать универсальный блог клиент, нужен протокол application-уровня, который будет оперировать понятиями «пост», «автор», «фид», «категория» и т.д. И такой протокол есть — AtomPub (http://tools.ietf.org/html/rfc5023). И — сюрприз — именно он и используется у нас в части общения с блогом :-).

                            Также этот протокол используется в Blogger (http://code.google.com/apis/blogger/, Google Data — это расширенный AtomPub), WordPress (http://codex.wordpress.org/AtomPub). Кроме того, этот же протокол поддерживает такой известный блог-клиент, как Windows Live Writer: jcheng.wordpress.com/2007/10/15/how-wlw-speaks-atompub-introduction/. Я, правда, не видел глазами, насколько WLW будет работает с Я.ру через AtomPub, предполагаю, что не сразу (поскольку мы таки в бете ещё), но мы будем рады поработать над этим с серверной стороны, если кому интересно.

                            Другими словами, слова «с нуля» и «велосипед» применимы как раз к ad-hoc XML-RPC решениями, которые только с виду выглядят очень простыми.
                              0
                              > Другими словами, слова «с нуля» и «велосипед» применимы как раз к ad-hoc XML-RPC решениями, которые только с виду выглядят очень простыми.

                              До этой фразы в общем-то понятно и логично. А вывод как-то совсем не клеится к тексту. XML-RPC радует своей простотой. В том же питоне посмотрите примеры — это просто песня.

                              Но хорошо, вам нравится REST. Хорошо, REST так REST, я еще раз повторю, что ниразу не оспариваю его технологических преимуществ, и согласен, что в целом он гораздо лучше удовлетворяет идеологии и духу WEB-а, применению URI схем, вместо надстроек и лент для публикации.

                              Но главный минус — без либ для основных языков. Согласитесь, что писать и парсить кучу XML-я, который весьма чувствителен к опечаткам — достаточно неприятное зенятие.
                                0
                                > XML-RPC радует своей простотой. В том же питоне посмотрите примеры — это просто песня.

                                Я не говорю о простоте конечного прикладного кода, я говорю об архитектуре. Любое кастомное XML-RPC сложно в освоении и поддержке, как раз потому что оно кастомно. А интеграция разных RPC-сервисов друг с другом часто совсем невозможна из-за отсутствия адресуемости ресурсов, например.

                                Простота конечного кода обеспечивается библиотекой прикладного уровня, независимо от того, какие запросы она в провода генерит. Никто не спорит, что с ней было бы приятней. С чем я спорю — так это с тем, что XML-RPC интерфейс заменил бы собой написание такой библиотеки руками.
                                  0
                                  А почему бы не заменил? Модуль того же питона xmlrpclib пока справлялся со всеми XML-RPC интерфейсами, которые мне приходилось встречать, независимо от их вендора.

                                  Только для одного из них пришлось сделать кастомный класс транспорта (около 10 строчек кода), т.к. там были нужны куки, а стандартный класс куки игнорирует. Все остальное цепляется и работает автоматом!
                                    0
                                    Я совсем не о том говорю. Разумеется XML-RPC предоставляет вам вызовы функций с конвертацией параметров элементарных типов. Только это и не задача вовсе, чтобы радоваться её решению. Задача — это интероперабельность на уровне приложений, а не на уровне транспорта.

                                    Попробую ещё раз. Если бы мы не использовали REST'ового подхода со стандартными MIME-типами, некому блог-клиенту пришлось бы изучать наш собственный протокол, и это *big deal*. А сейчас блог-клиенту для поддержки Я.ру надо, грубо говоря, знать, с какого URL'а у нас AtomPub начинается, и как авторизация делается. Это гораздо меньше, чем поддержка отдельного протокола.
                    0
                    Это здорово, давно ждал.
                      0
                      К вопросу об авторизации. Уже 2 день не могу авторизоваться ни в одном сервисе Я через FF. Выбираю например войти в почту, ввожу логин/пароль, после этого меня перебрасывает на страницу passport.yandex.ru/passport?mode=auth с текстом 404 — Not Found. В чём проблема, когда вы её исправите?
                        0
                        Только в FF такая проблема?
                          0
                          Проверил ещё раз FF и Chrome не авторизуют…
                            0
                            Какой логин у вас? Сразу после очередной ошибки зайдите, пожалуйста на internet.yandex.ru
                            Там нужно будет открыть ссылку «подробная информация», скопировать содержимое и прислать его мне — sasha-t@yandex-team.ru, постараемся разобраться
                              0
                              Спасибо за помощь, данные отправил.
                        0
                        Хмм… Гугл с Твиттером конечно работают через OAuth, но с версией 1.0а. Яндекс впереди планеты всей?
                          +2
                          Ага. Хотя прямо сейчас это скорее страшно, чем приятно :-). Потому что драфт OAuth 2.0 ещё сильно нестабильный. Мы будем стараться поспевать за изменениями.
                          +6
                          А вот длинный кусок на питоне, который меняет настроение программиста… :)
                            –1
                            Авторизация в Яндекс.Фотках не сложнее OAuth. Просто она своебразно документирована — кодом на C, а в части тонкостей XML-парсера на сервере не документирована вовсе. В своё время разобрались довольно быстро — см. nshare.ru/
                              +1
                              Яндекс продвигается в деле захвата мира: раньше можно было менять погоду, а сейчас ещё и настроение людей.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  возьмите и напишите, апи открыт.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Вопрос немного не по теме, но раз уж «Мы — разработчики Яндекса — внимательно слушаем, о чём нас просят пользователи, а также другие разработчики.», то скажите пожалуйста, будет ли когда-нибудь возможность добавлять комментарии в блоги на я.ру с openid? И её там нет по техническим или идеалогическим причинам?

                                  Мне кажется отсутствие openid — главное препятствие развитию блогохостинга на я.ру, потому что очень часто людям лень регистрироваться там, просто для того что-бы оставить коммент.
                                    0
                                    Не скажу ничего конкретного, кроме того, что про OpenID мы знаем, хотим, и думаем в том направлении. Но будет ли оно, и если да, то когда — не знаю. Слишком много переменных :-)

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

                                  Самое читаемое