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

61
задан 6 revs, 4 users 58%Jason 15 August 2012 в 23:35
поделиться

15 ответов

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

1
ответ дан 2 revs, 2 users 67% 24 November 2019 в 17:16
поделиться

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

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

4
ответ дан danielrsmith 24 November 2019 в 17:16
поделиться

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

2
ответ дан 24 November 2019 в 17:16
поделиться

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

Какие веб-API вы бы хотели воспроизвести больше всего или какие из них наиболее популярны?

0
ответ дан 24 November 2019 в 17:16
поделиться

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

0
ответ дан 24 November 2019 в 17:16
поделиться

Force (ранее известный как SalesForce) API: http://www.salesforce.com/us/developer/docs/api/index.htm

0
ответ дан 24 November 2019 в 17:16
поделиться

Что касается списка больших API Джеффа: я почти уверен, что общий не означает «золотой стандарт» .

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

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

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

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

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

8
ответ дан 24 November 2019 в 17:16
поделиться

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

Я сделаю первый удар:

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

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

3
ответ дан 24 November 2019 в 17:16
поделиться

Почему бы не написать свой собственный класс событий? Что-то вроде

class Event
  def initialize
    @handlers = Array.new
  end

  def fire
    @handlers.each do |v|
      v.call
    end
  end

  def << handler
    @handlers << handler
  end
end

e = Event.new

e << lambda { puts "hello" }
e << lambda { puts "test" }
e.fire

Это всего лишь минимальный образец, но может быть расширен любыми способами. Добавьте такие параметры, как sender и eventArgs в .Net или что угодно; -)

-121--2954718-

Профилировщик CUDA довольно грубый и не предоставляет много полезной информации. Единственный способ серьезно микрооптимизировать код (при условии, что вы уже выбрали наилучший алгоритм) имеет глубокое понимание архитектуры GPU, особенно в том, что касается использования общей памяти, узоров доступа к внешней памяти, использования регистров, заполнения потоков, деформаций и т.д.

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

Форум разработчиков nVidia CUDA также является хорошим местом для

-121--2583157-

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

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

11
ответ дан 24 November 2019 в 17:16
поделиться

Api Last.fm продолжает оставаться одним из наиболее хорошо поддерживаемых API в сети. Кроме того, он существует дольше, чем большинство других, потому что в основном это началось именно с этого.

http://www.last.fm/api

8
ответ дан 24 November 2019 в 17:16
поделиться

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

  • Facebook

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

    • GOOD: открытые стандарты (oAuth authentication, Opensocial endpoint)
    • BAD: часто нарушаются. Использование oauth очень нестандартно и ломает большинство клиентских библиотек. официальные клиентские библиотеки ужасны.
  • Photobucket (отказ от ответственности: я написал серверную часть фотоковша api)

    • GOOD: открытая стандартная аутентификация (oauth). xml, json, даже php сериализованный формат массива в качестве параметров ответа. верный REST (get/put/delete/post on 'noun' urls).
    • BAD: не много клиентских библиотек. Архитектурные проблемы со стандартными оаут-библиотеками (пользователи живут на субдоменах, вызовы должны быть сделаны в субдомен, поэтому url должен измениться).
  • Twitter

    • GOOD: довольно последовательный (хотя api против поиска api имеет различия). Хорошая практика REST. OAuth authentication, а также поддержка старой школы Basic.
    • BAD: количество ошибок (в основном совпадает с остальными твиттерами). Нечетный формат некоторых возвращаемых значений (например, их формат даты).

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

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

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

16
ответ дан 24 November 2019 в 17:16
поделиться

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

2
ответ дан 24 November 2019 в 17:16
поделиться

Как создать A Хороший API и почему это важно , 60-минутный технический доклад Google, сделанный Джошуа Блохом , является актуальным.

23
ответ дан 24 November 2019 в 17:16
поделиться

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

Наиболее часто встречающиеся ссылки на API сайтов:

Еще один список здесь:

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

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

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

37
ответ дан 24 November 2019 в 17:16
поделиться

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

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

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

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

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

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

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

0
ответ дан 24 November 2019 в 17:16
поделиться
Другие вопросы по тегам:

Похожие вопросы: