From 2ca9beac0b948bf995801ea468047fe79b50fc9f Mon Sep 17 00:00:00 2001 From: Sergey Konstantinov Date: Wed, 4 Feb 2015 00:03:27 +0300 Subject: [PATCH] =?UTF-8?q?=D0=90=D1=80=D1=85=D0=B8=D1=82=D0=B5=D0=BA?= =?UTF-8?q?=D1=82=D1=83=D1=80=D0=B0=20=D0=BF=D1=80=D0=BE=D1=82=D0=B8=D0=B2?= =?UTF-8?q?=20=D1=80=D0=B5=D0=B0=D0=BB=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- API.ru.html | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/API.ru.html b/API.ru.html index 81034dc..40dcba5 100644 --- a/API.ru.html +++ b/API.ru.html @@ -56,8 +56,9 @@

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

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

О проектировании API

-

Целесообразность

-

Если попытаться одной фразой описать основной принцип проектирования API, то можно ограничиться отним словом «зачем» и вопросительным знаком.

+

Архитектура против реализации

+

Поскольку API — обязательство, то к качеству его реализации предъявляются, как правило, повышенные требования — во-первых, в силу важности API как инструмента для бизнес-логики потребителей; во-вторых, в силу того, что ошибка в API может привести к гораздо более разрушительным последствиям, чем ошибка в end-user интерфейсе.

+

Попробуем объяснить на конкретном примере. Допустим, мы располагаем огромным и хорошо структурированным сервисом, предоставляющем метаинформацию, скажем, о . (Лично я никогда не делал подобных сервисов, но уже много лет испытываю в них нужду.)

Зачем такому сервису API?

Чтобы люди могли написать свои новые-кленовые аудиоплееры, использующие ваш сервис? Вряд ли.