Подтвердить что ты не робот

Каков золотой стандарт для API веб-сайтов? Twitter, Flickr, Facebook и т.д.

Похоже, сегодня есть две категории API для веб-сайтов.

  • API, которые позволяют расширить функциональность сайта, как Facebook, Myspace и т.д. Эти API кажутся очень разнообразными.

  • API, которые позволяют взаимодействовать с существующими функциональными возможностями сайта, такими как Twitter, Flickr и т.д. Все они утверждают, что они основаны на REST, но на самом деле просто "данные по HTTP".

Если вы создавали веб-сайт, который позволял как функциональное расширение, так и внешнее взаимодействие, какие существующие API вы использовали бы в качестве эталонной модели?

4b9b3361

ОТВЕТЫ

Ответ 1

Мы проводим некоторые исследования в этой области сами. Не так много в плане "золотой стандарт" для ссылок на API веб-сайта.

Наиболее распространенными API-интерфейсами веб-сайтов являются:

Другой список здесь:

http://www.pingable.org/the-top-15-web-apis-for-your-site/

Кто-то рекомендовал книгу Restful Web Services как хорошую ссылку на это.

(не стесняйтесь редактировать приведенный выше список, чтобы добавить другие сайты с высоким профилем с API)

Ответ 3

Поработав с несколькими, я вернусь к нему

  • Facebook

    • ХОРОШЕЕ: чистое и относительно последовательное. Выполняет хорошо, и большинство вещей логически имеет смысл. FQL довольно опрятен. Параметры XML и JSON. Нет предварительной концепции формата ответа, отличного от того, что вам действительно нужно
    • BAD: Изменения часто и без предупреждения. "официальные" библиотеки api довольно жестоки. документация по многим звонкам плохой или отсутствует. Нестандартная аутентификация (некоторые могут назвать это хорошим?)

  • Myspace

    • ХОРОШИЕ: открытые стандарты (аутентификация oAuth, Opensocial конечная точка)
    • ПЛОХО: часто нарушается. Использование oauth очень нестандартно и ломает большинство клиентских библиотек. официальные клиентские библиотеки ужасны.

  • Photobucket (отказ от ответственности: я написал серверную часть photobucket api)

    • ХОРОШЕЕ: открытая стандартная аутентификация (oauth). xml, json, даже php serialized array в качестве параметров ответа. верный REST (get/put/delete/post на 'существительных').
    • BAD: не так много клиентских библиотек. Архитектурные проблемы со стандартными библиотеками oauth (пользователи живут на субдоменах, вызовы должны быть сделаны для субдомена, поэтому URL-адрес должен измениться).

  • Twitter

    • ХОРОШО: довольно последовательный (хотя api vs search api имеет различия). Хорошая практика REST. Аутентификация OAuth, а также поддержка oldschool Basic.
    • BAD: частота ошибок (в значительной степени соответствует остальной части твиттера). Нечетный формат некоторых возвращаемых значений (например, их формат даты).

Идеальные характеристики

  • Я не продаюсь на "строгом" REST. PUT и DELETE вызывают проблемы на некоторых клиентских языках. GET и POST кажутся достаточными с соответствующими "глаголами". Кроме того, имена функций, похожие на RPC, со мной все в порядке, если они логичны и, возможно, даже часть URI. В этом случае объект IDS по-прежнему должен быть очень последовательным, хотя.
  • Стандартная аутентификация/авторизация. Basic/Digest может быть в порядке, но я поклонник OpenID/oAuth (или WRAP, если вы хотите получить краю кровотечения). Роллинг собственных средств вы должны объяснить 100% этого и потенциально писать клиентские библиотеки для всех.
  • Стандартные типы данных. Убедитесь, что вы согласны с вашими типами данных (либо "истина", либо 1, а не какая-то смесь) и поддерживайте самые общие стандарты. Datetime должен быть ISO8601. Геолокация должна выглядеть "GeoRSS" и т.д. Вы должны иметь возможность создавать XSD/relaxNG/любой строгий валидатор для возвращаемых типов. Ожидайте тех же стандартов от ваших входов.
  • Простая структура возврата. некоторые преимущества XML-RPC/JSON-RPC в том, что вы знаете, что вы получаете обратно, но в любом случае, если я не могу легко разобрать ваш тип возврата с помощью JSON или что-то вроде PHP SimpleXML и по существу сериализовать его на согласованный хеш, я буду злиться.
  • Поддержка расширения/расширения без поломки. Не вводите себя в угол и затрудняйте его добавление в свой API. Постарайтесь принять правильные решения перед тем, что вы не будете постоянно меняться.
  • Документация! Удостоверьтесь, что это хорошо, и все объясняет. Даже тогда это будет недостаточно, поэтому убедитесь, что у вас есть время для работы над ним и форума поддержки или что-то еще, чтобы поддерживать его в актуальном состоянии.

Итак, чтобы сказать... что-то между Facebook и Twitter. Конечно, я частично отношусь к некоторым вещам, которые мы имеем на Photobucket, но я также ненавижу некоторые из них.

Ответ 4

Мне кажется, что документация API как важна (или более), чем фактический дизайн API.

Хорошо написанная, простая документация будет компенсировать любые недостатки дизайна. Это то, что я узнал после просмотра различных ссылок, уже опубликованных. В частности, документация Last.fm кажется очень хорошей: легко ориентироваться и легко понять.

Ответ 5

Last.fm api по-прежнему остается одним из самых хорошо поддерживаемых apis в сети. Это также было дольше, чем большинство, потому что это началось в основном как только.

http://www.last.fm/api

Ответ 6

Относительно списка больших API-интерфейсов Jeff: я уверен, что обычный не означает "золотой стандарт".

Не нужно вести список ручных API. Чтобы получить список, выполните http://www.programmableweb.com/apis/directory/1?sort=mashups.

Поскольку мне нравится REST как свободный стандарт, я бы сказал, что API является "золотым", когда он имеет смысл и интуитивно понятен.

... все имеют для меня смысл и хорошо продуманы (как уже указывал Брайан).

В моей текущей ежедневной работе я также много работаю с OpenSocial, где URI очень естественны, но также расширяют стандарт REST по-своему.

Если вам нравится это строго и безопасно, используйте SOAP.

Ответ 7

Я бы посмотрел OpenSocial, движение для создания стандарта API для социальных сетей. Они используют REST для этого и имеют ориентированный на пользователя подход. Но это очень хорошо документированный подход, который может помочь даже для сайта, который не является полностью социальным. Если вы ищете некоторые внутренние реализации кода, посмотрите на систему захвата Drupals и Wordpress.

http://code.google.com/apis/opensocial/

Ответ 8

Я думаю, что лучший способ ответить - это перечислить характеристики хороших веб-API, а не приводить примеры. Если вам нравятся API Twitter/Facebook/etc, какой аспект этих API вы считаете привлекательным?

Я возьму первый удар:

  • Хорошо документированные API, включая ограничения и политики использования. Это позволяет быстро развиваться с уверенностью, вместо того, чтобы догадываться, что могут означать параметры и каковы значения возврата.
  • API/агностические агенты языка. Хорошие API-интерфейсы должны быть легко доступны, предоставляя одинаковые функциональные возможности на широком спектре языков и платформ.
  • Поддерживаемые API. Всегда есть ошибки. Отзывчивые сопровождающие приводят к использованию более удобных API.
  • Многоуровневые наборы API. Когда API-интерфейсы аккуратно накладываются друг на друга, широкий круг разработчиков может потреблять части, в которых они нуждаются, без необходимости вытягивать посторонние слои. В качестве плюса он заставляет творцов задуматься о чистых и компонентных API-интерфейсах.

Пожалуйста, добавьте больше комментариев.

Ответ 9

У меня нет опыта с другими, но, несмотря на то, что он эволюционировал с годами, API Facebook по-прежнему ужасен. Он нигде не приближается к "золотому стандарту". Скорее, это то, над чем люди борются и царапают зубы, потому что, как только они наконец вернутся, это может добавить большую ценность.

Ответ 10

Некоторые API, которые особенно хороши:

Ответ 11

Это будет зависеть от вашей целевой аудитории. Если это магазины .net, то мыло, вероятно, подходит и другим мудрым акцентом на REST, так как у него гораздо более низкий уровень входа. Оттуда посмотрите API-интерфейсы веб-сайтов, которые предназначены для тех же людей, которых вы хотели бы. Таким образом, ваш api будет чувствовать себя знакомым.

Ответ 13

AtomPub - золотой стандарт, потому что он был разработан некоторыми из самых ярких умов в Интернете. Вы не можете ошибиться, используя iit в качестве основы. Это то, что делают google и msft.

Ответ 15

Если бы я разрабатывал веб-api сегодня для существующего веб-сайта, предполагая, что веб-сайт был хорошо разработан в отношении его правильного использования HTTP, я бы использовал существующий веб-сайт в качестве руководящего принципа дизайна.

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

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

На самом деле сложное решение - это тип медиа-типа для использования. Вы можете использовать hotml с голыми костями с разметкой метаданных в стиле RDFa или разыгрываться и использовать новый формат Microdata в Html5. Или вы можете вернуть пользовательский тип носителя на основе xml или Json. Что-то вроде application/vnd.stackoverflow.question + xml и т.д. Пользовательский тип носителя делает управление версиями очень легким, но он менее доступен для клиентов, которые не были предназначены для прямого доступа к StackOverflow. Пользовательские типы могут использоваться в сочетании с Atom-каналами, которые в основном присутствуют в StackOverflow,

Разработка веб-api действительно ничем не отличается от проектирования веб-сайта, за исключением того факта, что вы доставляете контент, который будет потребляться программой, которая не является веб-браузером.

Что вы не хотите делать, это создать слой доступа к данным на основе Http. Это похоже на то, что вы показываете свое нижнее белье миру. Существующий веб-сайт оптимизирован для всех распространенных сценариев использования, многие из шаблонов доступа api будут похожи, поэтому повторное использование "представлений", которые уже были созданы. Может потребоваться добавить несколько дополнительных ссылок здесь и там, чтобы сделать программы для получения желаемых данных, но они могут быть добавлены постепенно по мере необходимости.

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