В книге об ОС я только что прочитал: «Публичные API вечны: только один шанс сделать это правильно». Это правда? Это применимо только в API операционных систем или других API тоже? Например, будет ли это так для API-приложений Android, таких как Tasker, Locale и Pushover?
android
api
api-design
Md Mahbubur Rahman
источник
источник
Ответы:
Как правило, это верно для любого публичного 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 «2.0» (есть несколько примеров, когда это происходит - в настоящее время я могу вспомнить, что Strava выпустила). версия 2.0 API для разработки против использования их услуг).
Проблема заключается в поддержке этого оригинального API до бесконечности ... Я полагаю, что это зависит от использования старого API и от того, какое значение имеют эти потребители API.
Возвращаясь к «старым временам», скажем, Windows 3.x и 9x и т. Д., После выпуска эти API-интерфейсы для ОС были созданы и настроены. Теперь обновления ОС загружаются все время, поэтому можно выпускать новые API, но я думаю, что пока вы работаете с определенной разновидностью ОС (основной выпуск), эти API будут только добавляться, а не удаляться ... может и не быть будь случай для 'следующего' основного выпуска все же.
Хм, может быть, я отклонился от первоначального намерения.
источник
Это зависит от того, какой это API (и я предполагаю критические изменения, в противном случае утверждение явно не соответствует действительности).
Если вызывающий может выбрать, какую версию он использует (например, с библиотеками / средами, которые связаны с вызывающим приложением), то изменение API не является большой проблемой - но все же плохо сказывается на репутации программного обеспечения. Людям нравится обновляться без проблем.
С другой стороны, когда люди не могут продолжать использовать старую версию API (например, с онлайн-службой или такими вещами, как браузер или ОС, где запуск старых версий очень нежелателен), тогда изменение API несовместимым способом очень плохо на самом деле, поскольку он сломает все программное обеспечение, которое его использует, а также не обновляется. Это налагает затраты на обслуживание на разработчиков, и они будут ненавидеть вас за это. А программное обеспечение, которое не обслуживается и ломается, плохо отразится и на вас.
С другой стороны, есть по крайней мере один провайдер API, который постоянно вносит серьезные изменения в API и в любом случае смехотворно успешен: Facebook. Но они управляют изменениями очень осторожно: существует опубликованная политика , о критических изменениях объявляется и объясняется по крайней мере за 90 дней до начала, и разработчики могут активировать их рано в течение этого периода времени.
источник
Если у вас есть предвидение, чтобы включить номер версии в самом API. Либо при вызове соединения / инициализации, либо где-то рядом с началом списка параметров при каждом вызове, ваш API может развиваться и изменяться со временем, не нарушая работу существующих клиентов.
источник
Хотя все, что мы делаем, - это чтобы они были лучшими за один раз, но с течением времени наступают перемены и улучшения, иногда нам нужно обновлять информацию, как это делали многие гигантские провайдеры (например, обновление фейсбука несколько, твиттер одно главное) Обращаясь к oAuth и нескольким основным, но, по большей части, все идет с улучшением, поэтому никаких частых изменений нет. И да, пожалуйста, не прекращайте поддерживать старый, это больно !! :)
источник
Каждый раз, когда вы выпускаете какой-либо протокол связи, который, очевидно, включает в себя API, у вас есть один шанс сделать это правильно в том смысле, что протокол / интерфейс должен быть обратно совместим и расширяем.
Это позволяет добавлять новые функции и выпускать новые версии, не беспокоясь о том, чтобы сломать людей, использующих старые версии. Никогда в мире программного обеспечения не возникнет ситуация, когда вы можете просто жестко переключаться в определенный момент времени, и все отбрасывают старую версию и начинают использовать новую версию.
источник