"Громадські API - це назавжди. Є лише один шанс виправити це"?

У книзі про ОС я щойно прочитав це: "Загальнодоступні API є назавжди. Лише один шанс виправити це правильно". Це правда? Чи застосовується це лише в API операційних систем або інших API? Наприклад, чи справедливо це для API таких програм Android, як Tasker, Locale та Pushover?

Як правило, це стосується будь-якого публічного API, так. Після того, як ви відкриєте API для громадськості, і люди почнуть створювати додатки, які залежать від цього API, змінити API стане вкрай важко, оскільки це порушить усі ці програми. Це, як правило, є як важкою технічною проблемою, так і важкою політичною проблемою.

Звичайно, можна змінити публічний API. Так трапляється, наприклад, що проекти будуть видаляти API в одному випуску, вводити новий API і потім видаляти старий API в майбутньому випуску. Але це передбачає, що кожна (важлива) програма, яка використовує старий API, буде переписана для використання нового API перед тим, як старий API буде видалений. Це часто займає кілька років. А це означає, що власник публічного API накладає витрати на кожен інший проект, який споживає API. Оскільки, як правило, значно більше споживачів API, ці споживачі, як правило, є відносно потужним політичним лобі.

Автор цитата - Джошуа Блох, заява - з статті про дизайн дизайну API Bumper-Sticker :

Публічні API, як алмази, назавжди. У вас є один шанс виправити це, тому дайте все можливе.

Більш детально про це автор звертається до читачів із презентацією своєї сесії конференції "Як створити хороший API та чому це має значення" . Слайд Чому для вас важливий дизайн дизайну API, досить чітко зазначено, що це стосується будь-якої діяльності програмування (операційні системи чи ні, для автора не має значення):

• Якщо ви програмуєте, ви - дизайнер API

  • Хороший код модульний - кожен модуль має API

• Корисні модулі мають тенденцію до повторного використання

  • Коли модуль має користувачів, не можна змінювати API за бажанням
  • Хороші багаторазові модулі - це корпоративні активи

• Мислення з точки зору API покращує якість коду

Висновок слайдів також підкреслює це як загальний підхід:

• Дизайн API - це благородне та корисне ремесло

  • Покращує кількість програмістів, кінцевих споживачів, компаній ...

API завжди змінюються, інакше який би був сенс оновлення системи? Змінення лише внутрішніх даних?

Кожна версія системи приносить нові API, старі API застарівають, а застарілі API зникають.

Зміни API повинні бути дуже обережними як технічно, так і з точки зору зв'язку.

Я вважаю, що колись випущена, ця "версія" API є назавжди, але ви можете знехтувати її, випустивши API "2.0" (є кілька прикладів, коли це відбувається - наразі я можу подумати про Страву, який випустив версія 2.0 для розробки API для споживання їхніх послуг).

Проблема полягає в підтримці оригінального API ad infinitum API ... Я думаю, це залежить від використання старого API та від того, яке значення мають ці споживачі API.

Повертаючись до «старих часів», скажімо, Windows 3.x та 9x тощо, після випуску ці API-програми ОС були зроблені та встановлені. Тепер оновлення ОС постійно надсилаються, тому нові API можна випускати, але я думаю, що доки ви використовуєте певний аромат ОС (основний випуск), ці API додаватимуться до них, ніколи не видаляються ... можуть не все ж таки має місце для головного випуску "Наступний".

Хм, можливо, я відмовився від початкового наміру питання.

Це залежить від типу API (і я припускаю порушення змін, інакше твердження явно не відповідає дійсності).

Якщо абонент може вибрати, яку версію вони використовують (наприклад, з бібліотеками / рамками, які входять до виклику програми), то зміна API не є величезною проблемою - але все-таки погана для репутації програмного забезпечення. Люди люблять модернізувати оновлення.

З іншого боку, коли люди не можуть продовжувати користуватися старою версією API (наприклад, через Інтернет-сервіс або такі речі, як браузер чи ОС, де запускати старі версії дуже небажано), то зміна API не сумісним чином дуже погана Дійсно, оскільки воно порушить усе програмне забезпечення, яке його використовує, а також не оновлено. Це накладає витрати на технічне обслуговування розробників, і вони вас за це ненавиджу. А програмне забезпечення, яке не підтримується і не працює, також буде погано відображатися на вас.

На руках, щонайменше, є принаймні один постачальник API, який постійно впроваджує проривні зміни в API і все одно смішно успішний: Facebook. Але вони керують змінами дуже обережно: існує опублікована політика , порушення змін оголошуються та пояснюються принаймні за 90 днів до цього, і розробники можуть вирішити активувати їх на початку цього терміну.

Якщо у вас є передбачливість включити номер версії в сам API. Або під час виклику підключення / ініціалізації, або десь біля початку списку параметрів кожного виклику, ваш API може еволюціонувати та мутувати з часом, не порушуючи існуючих клієнтів.

Хоча все, що ми робимо, - зробити їх найкраще за один раз, але оскільки приходить зміна та вдосконалення часу, іноді нам потрібно оновлювати інформацію, як це робило багато гігантських постачальників послуг (як-от оновлення декількох книг, щебетати один головний звертаючись до oAuth та декількох основних, але в кращому випадку все відбувається з поліпшенням, тому ніяких частих змін немає. І так, будь ласка, не припиняйте підтримувати старіший, боляче !! :)

Щоразу, коли ви випускаєте будь-який протокол зв'язку, який, очевидно, включав би API, ви маєте один шанс виправити це в тому сенсі, що протокол / інтерфейс повинен бути сумісним назад і розширюваним.

Це дозволяє додавати нові функціональні можливості та випускати нові версії, не турбуючись про те, щоб зламати людей, які використовують старіші версії. Ніколи в світі програмного забезпечення у вас не виникне ситуація, коли ви можете просто зробити жорсткий переріз в певний момент часу, і кожен скидає стару версію і починає використовувати нову версію.