Цитаты из книги   Паттерны проектирования API

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

Однозначно определить, что значит «хороший» API, сложно, но обычно они отличаются функциональностью, выразительностью, простотой и предсказуемостью

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

API без сюрпризов опираются на повторяющиеся паттерны, применяемые и к внешнему определению API, и к его поведению. Например, если API перевода текста содержит метод TranslateText(), который в качестве параметра получает входное содержимое в поле text, то при добавлении метода DetectLanguage() входное содержимое должно также называться text (а не inputText, content или textContent).

Если посмотреть немного под другим углом, то ресурсно-ориентированные API — это просто особый тип API, основанных на RPC, в которых каждый RPC следует понятному и стандартизированному паттерну: ().

с помощью какого из методов мы просматриваем все свои брони: ShowFlights(), ShowAllFlights(), ListFlights() или ListAllFlights() (в данном случае это ShowAllFlights()). Но как можно решить такую проблему? С помощью стандартизации.

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

начинается с рассмотрения ряда общих принципов проектирования, и далее описывается набор паттернов проектирования, которые могут предоставить простые решения для типичных сценариев создания API

Говоря, что набор операций является атомарным, мы имеем в виду, что они неотделимы друг от друга.

Начнем с самого важного: вне зависимости от того, как будет выглядеть окончательный интерфейс, система в целом должна быть функциональной.