Для чего нужно api
Что такое API и как он помогает в создании программных систем
Программы, как люди, общаются между собой. Разбираемся, как это происходит с помощью API.
Популярный термин API (англ. Application Programming Interface — программный интерфейс приложения) — это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными.
Все эти коммуникации происходят с помощью функций, классов, методов, структур, а иногда констант одной программы, к которым могут обращаться другие. Это основной принцип работы API.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Почему API называют интерфейсом
Интерфейс — это граница между двумя функциональными системами, на которой происходит их взаимодействие и обмен информацией. Но при этом процессы внутри каждой из систем скрыты друг от друга.
С помощью интерфейса можно использовать возможности разных систем, не задумываясь о том, как они обрабатывают наши запросы и что у них «под капотом». Например, чтобы позвонить, совсем не обязательно знать, как смартфон обрабатывает нажатия на тачскрин. Важно лишь, что у гаджета есть «кнопка», всегда возвращающая одинаковый результат в ответ на определённые действия.
Точно так же с помощью вызовов API можно выполнить определённые функции программы, не зная, как она работает. Поэтому API и называют интерфейсом.
Как API помогают писать надёжные программы
Программную (и не только) систему, внутреннее устройство которой скрыто или не важно при решении текущей задачи, принято называть « чёрным ящиком» — потому что мы не знаем/не принимаем во внимание то, что там происходит. А само сокрытие деталей реализации — уровнем абстракции.
Уровни абстракции сильно ускоряют процесс разработки, потому что программист может использовать готовые функции API в других приложениях. Это обычная практика. Например, большинство операционных систем предоставляют свои API другим программам, чтобы они получили возможность:
Windows, Linux или OS X сами определяют, какие функции нужно вызвать и какие параметры передать, чтобы были выполнены те или иные действия. Всё это описывается в документации к API, с которым работают разработчики других программ.
Если создатели API выпускают обновление, которое исправляет ошибки, устраняет уязвимости или улучшает производительность, все приложения, использующие это API, автоматически станут работать лучше.
Если какой-то API для облачных вычислений станет быстрее извлекать квадратный корень, то и все использующие его программы тоже начнут работать быстрее: от онлайн-калькуляторов до нейросетей.
Почему API так популярны у программистов
Стороннее API обычно безопаснее, потому что над ним работает коммерческая организация или целое сообщество разработчиков.
Какие функций могут входить в API
Никаких специальных правил или ограничений на набор функций для API нет — разработчики включают в него то, что позволит клиентам использовать нужные возможности приложения.
Например, в API для анализа текстов будут функции поиска всех однокоренных слов, подсчёта количества союзов, выявления часто встречающихся словосочетаний и так далее.
Функции API могут решать не только утилитарные задачи конкретных приложений. Это может стать элементом маркетинга, когда доступ к API предлагается в виде отдельной услуги.
Как компании зарабатывают с помощью API
Компании, разрабатывающие сложные программные системы, часто предоставляют клиентам доступ к API своих продуктов. Например, создатели видеоредактора могут брать дополнительную плату за рендеринг видео на своих серверах. По API они принимают от клиентов все файлы и инструкции, а возвращают готовый ролик.
Так, скажем, Яндекс, помимо прочего, предоставляет платный API своих технологий:
Популярные социальные сети тоже предоставляют доступ к своим API. Через них можно, например, создать игру для ВКонтакте или добавить на сайт авторизацию через Facebook.
При этом компании обычно не раскрывают принципы реализации своих API, поэтому для программистов они остаются «чёрными ящиками».
Как происходит вызов функций API
Способ вызова функции API описывается в документации.
Вот пример вызова методов библиотек в языке Python:
Если API предоставляет функции через интернет (WebAPI), нужно отправить на сервер HTTP-запрос с данными в формате JSON. Пример синтеза речи с помощью API Yandex.SpeechKit:
Этого достаточно, чтобы получить следующее аудио:
Также бывают косвенные вызовы API — когда вызов происходит при участии посредника (другой функции или другого API). Например, когда пользователь нажимает кнопку «Обновить», он тоже взаимодействует с API браузера. Но делает это не напрямую, а через графический интерфейс.
Что в итоге
С развитием технологий использование API, вероятно, станет повсеместным. Даже простейшие встраиваемые системы, вроде «умного утюга», которые состоят из одной программы, сейчас всё активнее подключаются к интернету вещей. Для этого тоже используют API.
Программисту нужно не только уметь создавать свои интерфейсы для взаимодействия программ, но и знать, как использовать чужие. Научиться работать с API вы сможете на наших курсах по программированию — выбирайте любой и становитесь востребованным специалистом.
API: что это такое в программировании и как работать с ним
Аббревиатура API встречается повсюду: в программных обеспечениях, интернет-протоколах, на сайтах. API используют многие сервисы и приложения. В статье объясним, зачем нужен API, расскажем о функциях и принципах его работы.
Что такое API и почему его называют интерфейсом
API (Application Programming Interface или программный интерфейс приложения) – это совокупность способов, протоколов, инструментов, с помощью которых различные программы обмениваются своими возможностями, данными, выполняют разные функции.
Зачем нужен API
API создан для удобства. Когда пользователь работает с планшетом или другим девайсом, ему не приходится вникать, как компьютер обрабатывает информацию: он просто нажимает на иконки в интерфейсе. Аналогичная ситуация с API. Благодаря программному интерфейсу разработчик может подключить свой продукт к другим системам для хранения файлов, отрисовки графики, воспроизведения видео или аудио. При этом ему не приходится писать собственный код или разбираться, как именно работает ОС. Такой алгоритм упрощает и ускоряет процессы.
Почему разработчики используют API
Перечислим основные причины интереса программистов к применению API:
Функции API
Некоторые компании предлагают API в качестве отдельного программного продукта. Допустим, вы хотите встроить интерактивные карты на сайт интернет-магазина, чтобы покупатель мог найти ближайший пункт выдачи товара, и выбираете API Яндекс.Карт. Разрабатывать собственный картографический сервис не придется. Сервис сайта отправит запрос к сервису Яндекса на поиск организаций на карте, а после получения ответа отобразит данные в браузере покупателя.
Типы API
Типы APIПо типу доступа программные интерфейсы API бывают:
WEB API, которые используют для создания HTTP-служб:
Использовалась, когда системы были связаны в локальных сетях. Принцип работы: вызов удаленных систем похож на вызов функций внутри программы. Яркие примеры таких систем – CORBA и DCOM.
Это протокол для обмена сообщениями в распределительной вычислительной среде. Помимо удаленного вызова процедур, SOAP способен отправлять и получать сообщения формата XML. Работает с протоколами прикладного уровня.
Это архитектура ПО для веб-служб. Обеспечивает работу с любыми форматами, будь то сайт, flash-программа, приложение другого формата и другие. Благодаря тому, что данные передаются без дополнительных слоев, REST использует меньше ресурсов, так как на каждую передачу данных требует меньше запросов.
Плюсы работы с API
Преимуществ работы с интерфейсом программирования много. Основные из них:
Как использовать API
Основная функция API – построение эффективной коммуникации между программами. Для разных целей интерфейс выполняет разные задачи.
В контексте интернета
Программный интерфейс позволяет быстро и просто получить доступ к источникам из другого программного приложения.
Например: зайти в личный кабинет интернет-магазина или профиль в социальной сети можно и через аккаунт на других веб-ресурсах. Это возможно благодаря API, установленным непосредственно в социальные сети. Код и API этих платформ дает клиентам доступ к другим приложениям.
В партнерском маркетинге
Работа с API в партнерском маркетинге облегчила труд программистов. Ранее они работали в SaaS – интеграции, которая предоставляла ПО как услугу посредством веб-интерфейса. Большую часть работы в сервисе приходилось выполнять вручную: это замедляло развитие партнерских программ и отражалось на стоимости работ. Теперь же программисты используют API как сравнительно быстрый и дешевый аналог.
Calltouch тоже может упростить работу и освободить время для решения более важных задач. Наши продукты помогают вашему бизнесу оптимизировать расходы на маркетинг.
Эффективный маркетинг с Calltouch
Особенности современного API
API сегодня — это товар. А его покупатели – разработчики ПО. Поэтому API постоянно дорабатывают, делают его доступным и удобным, выпускают регулярные обновления и занимаются поддержкой. Высокий спрос повышает качество продукта. Чтобы привлечь больше пользователей, разработчики создают новые идеи и дорабатывают ошибки, делают связь между приложениями надежнее и безопаснее.
Основные и наиболее популярные категории API
Чаще всего разработчики используют следующие типы интерфейсов:
Примеры API
Посмотрим, как разработчики интегрируют сайты и приложения с внешними сервисами, используя API, и как это влияет на функционал веб-продукта.
Google Календарь
Google Calendar API взаимодействует с приложениями, связанными с бронированием, организацией мероприятий и иными событиями, для которых нужно выделять время. Приложение синхронизирует данные из нескольких сервисов и позволяет просматривать, редактировать и удалять информацию о будущих событиях в одном месте.
Например, пользователь заказал билет на самолет или на концерт. Google Calendar API автоматически добавит дату и время полета или мероприятия в календарь.
Погодные приложения
Большинство погодных приложений пользуются API. Их разрабатывают сервисы, которые сотрудничают с метеостанциями напрямую.
Приложение делает запрос о погоде в конкретной геолокации. Программный интерфейс обрабатывает его и связывает с метеорологическим спутником, а после передает информацию пользователю.
Сервис по заказу авиабилетов
Билеты на самолет можно купить на сайте авиакомпании, но есть специальные сервисы, которые помогают найти подходящий рейс на указанные даты по выгодной цене. Агрегатор отбирает данные с разных сайтов и показывает ее в одном окне. В России по такому принципу работает известный агрегатор Aviasales.
Чтобы быстро собирать актуальную информацию, разработчики приложения для покупки билетов пользуются API сервисов авиакомпаний.
Умный сервис сквозной аналитики от Calltouch так же работает по умному принципу: система объединяет данные о разных маркетинговых мероприятиях компании и создает информативные и понятные отчеты. Закажите сквозную аналитику и сократите бюджет на бесполезную рекламу.
Сквозная аналитика
Кнопки авторизации
Навигация на сайтах и в приложениях
По аналогии с работой погодных приложений, другие сервисы тоже пользуются данными программных интерфейсов. Спутники предоставляют геоданные для тех или иных приложений. С ними работает API, проецируя на графический интерфейс карту. Эта карта используется не только в приложениях-навигаторах, но и в сервисах для вызова такси или заказа курьерской доставки.
Зачем создавать собственный API
Теперь обозначим частые ситуации, в которых удобно использовать API для собственных веб-продуктов:
Как вызывать API
Разработчики предоставляют пользователям подробное руководство по работе с интерфейсом. Обычно вызов происходит прямым и косвенным способами.
Вызов API напрямую
Это способ, при котором пользователь целенаправленно работает с API и ее функционалом.
Система вызывает функции внутри себя
Пользователь делает вызов из интерфейса. При этом составные части API связываются друг с другом на программном уровне. Допустим, первая функция интерфейса связана с удалением строки из таблицы. Она вызывает вторую для обновления данных.
Система вызывает метод другой системы
Этот способ мы уже описывали ранее. Используется, когда система хочет получить или отправить данные из совершенно другой ОС. Например, разработчик подключает к своему сайту сторонний сервис: сайт отправит запрос на удаленный ресурс через API и отобразит полученный ответ.
Вызов метода пользователем
Применяется тестировщиками, чтобы:
Можно вызывать метод без графического интерфейса вручную, если он содержит ошибки или пока не работает.
Автотесты вызывают методы
Автотест — это робот, который ищет ошибки в приложении, имитируя действия пользователей. В некоторых случаях удобно это делать не через GUI, а через API. Разработчик вносит данные на вход и проверяет их на выходе: так легче выявить и устранить баги.
Косвенный вызов
Каждый пользователь, открывая программу, работает с API. Например, нужно создать вкладку в браузере. Мы нажимаем кнопку и вызываем API, скрытый под удобным пользовательским интерфейсом. То есть, выполняя действие, мы отправляем команду множеству функций, но видим только результат — открытую вкладку.
Как тестировать API
Здесь нужно уточнение. Строго говоря, тестируется не сам программный интерфейс, а функционал сервиса с использованием API. Используя это выражение, программисты имеют в виду автотесты на уровне API. В отличие от тестирования GUI, здесь тестируется бизнес-логика и архитектура приложения.
Прежде чем приступать к работе, настраивают среду, в которой будет тестироваться интерфейс. Есть несколько видов тестирования:
После проведения работ, тестировщик анализирует результаты теста.
Заключение
API это необходимый элемент многих сайтов и приложений. Он помогает разработчикам создавать удобные сервисы в сжатые сроки, сохраняя ресурсы. Благодаря API для своих проектов можно использовать чужие веб-продукты, а можно создавать свои и делиться ими с другими. С развитием технологий применение программного интерфейса станет повсеместным.
Вы зарабатываете на информации (зачем нужен API и как его грамотно спроектировать)
Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
Информация — основа любого приложения или сервиса.
Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?
Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.
Цель вашего приложения, какое бы оно ни было — донести (получить, обработать) некоторую информацию до пользователя.
Даже если это будет ужасный, некрасивый и неудобный сайт, пользователи всё равно найдут тот товар, который искали. Особенно, если вы торгуете чем-то достаточно уникальным (хотя бы в вашем регионе). Плюс поисковики вам помогут, выводя пользователя сразу к нужному товару.
Конечно, конверсия может быть ниже, или пользователь может быть не очень доволен опытом работы с сайтом, но, если сам товар будет именно тем, что он искал — всё остальное будет малозначимо.
Я не рассматриваю магазины, продающие «на эмоциях», и покупки, о которых пользователь может потом пожалеть.
Примеры могут варьироваться в зависимости от жанра и других параметров, но в целом пользователя интересуют такие вещи, как история мира, переписка/общение с союзниками, информация о текущих событиях, информация об его персонаже/деревне/корабле/чем-угодно-другом.
Очень часто способ доступа к этой информации уходит за пределы самого клиента игры. С помощью мобильного приложения можно проверить, не нападает ли на тебя кто, или выставить какие-нибудь товары на внутриигровой аукцион, даже не заходя в саму игру.
Пользователь хочет найти интересующую его музыку. Все обёртки, умные очереди, лицензионность и прочая шелуха мало кого интересует.
Конечно, хорошо использовать лицензионный контент, но если пользователь не может найти то, что искал — он уйдет и найдет это в другом месте. В интернете люди не запоминают информацию как таковую, они запоминают место, где эту информацию нашли. Поэтому, если на вашем сайте нет песен группы Х, но зато есть ссылка на страницу группы Х, где они продают свои альбомы, ваш сервис все равно в плюсе, потому что пользователь запомнил, где он взял информацию о группе Х и вернется к вам еще раз поискать информацию о группе Y.
Я работал в нескольких музыкальных проектах, и очень часто всё упиралось именно в наличие необходимых треков, несмотря на десятки терабайт данных.
Думаю, идею вы уже уловили. Примеры можно приводить бесконечно (вот ещё один: на википедию не за дизайном ходят. Более того, часть информации с википедии выводится сразу в поисковой выдаче, без открытия даже самого сайта), и если думаете, что в вашем случае это неприменимо — напишите в комментариях (или на почту / в личку), и я объясню, почему всё же применимо.
Так вот: чем бы вы ни занимались, первичной всегда будет информация. Хорошую, качественную информацию пользователи обязательно найдут и обратятся к вам.
Я расскажу, как организовать работу с информацией так, чтобы это было:
1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
2. Удобно для пользователей — легко документировать, понятно как использовать.
3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.
Данный подход не имеет смысла для вас, если у вас маленький проект с небольшим количеством компонентов и разработчиков.
В тексте статьи я использую ряд допущений: например, что у вас уже что-то имеется или реализовано.
Практически в каждый из вопросов можно углубляться бесконечно, по объему подробный разбор тянет на целый цикл подобных статей. Если какая-то информация не была указана — я посчитал, что для восприятия концепта она не важна.
Если считаете, что всё же чего-то не хватает — пожалуйста, сообщите, и статья будет дополнена в соответствии с пожеланиями.
Потребители информации
Потребителей информации можно разделить на две категории — внутренние и внешние.
Внутренние — это ваши же продукты и сервисы. Разница в том, что для «своих» API может предоставлять гораздо более широкий функционал с меньшими ограничениями. Например, те же карты гугла на собственном домене могли работать с применением webgl, и как следствие, значительно быстрее, а встраиваемые — нет (на текущий момент ситуация могла измениться, не проверял).
Внешние — конечные пользователи или продукты, не принадлежащие вашей компании. Например, для карт гугл вы являетесь внешним пользователем. Обычно доступ к информации извне сильно ограничен, и часто требуются специальные ключи доступа.
Как работать с информацией?
Для работы с информацией мы будем предоставлять web API. Реализовывать будем 2 слоя (внешний и внутренний). Слой подразумевает, как минимум, отдельное приложение.
API позволяет предоставлять данные в платформонезависимом виде. Не всегда известно, каким образом и где будут использоваться данные, и разработка API — хороший способ заявить «у нас есть информация — обращайтесь к нам».
Все примеры кодов — лишь один из многих вариантов реализаций. Это обеспечит возможность использования данных независимо от способов реализации конечного продукта (включая оффлайн приложения, при условии хотя бы единовременного выхода в сеть).
В первую очередь необходимо описать модели и коллекции данных. В случае если приложение реализуется на Javascript (nodejs на сервере), появится возможность использовать одни и те же модели и на клиентах, и на серверах.
Модель — описание некоей сущности (например, музыкальный трек): её поля, их свойства, способы доступа и предоставления информации. Модель может дублировать схему базы данных, но также может расширять её дополнительной информацией. Более того, модель может содержать информацию из нескольких таблиц/коллекций и представлять её как одну сущность. На сервере модель должна быть расширена описаниями по работе с таблицами, доступами к серверам и так далее. На клиенте модель расширяется адресами доступа к данным.
При обращении к данным модель может содержать также дополнительную метаинформацию о самом запросе (время выполнения, позиция записи в базе, связи), виртуальные поля (например, если в базе хранится path — относительный путь до файла, можно добавить виртуальное поле url, которое будет вычисляться «на лету»).
В качестве примера я приведу код, описывающий некий музыкальный сервис.
Примеры будут на Javascript, однако всё описанное применимо к любому языку. Я делал подобные вещи также на php, python и c++. Всё необходимо варьировать в зависимости от размеров проекта.
Чтобы не захламлять код, я опущу подробные описания проверок в примерах. При желании можно указывать любое количество критериев, тексты ошибок валидации и т.п.Валидация применима как на клиентах, так и на серверах.
Коллекция — набор сущностей (обычно одинаковой природы, то есть, к примеру, музыкальные треки). Набор данных также может содержать дополнительные, относящиеся к самому набору, данные. В качестве метаинформации может быть представлено количество выбранных треков, количество оставшихся (не выбранных) треков, номер страницы, количество страниц. Виртуальным полем может быть общая продолжительность всех треков.
Внутренний слой API
Этот слой будет доступен только нашим продуктам.
Так как наши модели уже содержат много информации, мы можем предоставить доступ к данным, используя минимальное количество кода.
Расширяем модель на сервере и клиенте, описывая название и путь. Общие реализации методов findOne, update, destroy и create описаны в абстракции модели и не требуют отдельной реализации, если принципиально не отличаются.
Расширяем модель только на сервере:
Расширяем модель только на внутреннем клиенте:
На этом слое мы имеем максимальную гибкость запросов.
В ответ получаем что-то типа:
Не обязательно именно так вкладывать информацию. Если боитесь дубликатов (хотя, если в плане трафика, то gzip с ними отлично справляется), можно собирать в отдельные поля в начальный result.
Внешний слой API
Внешний слой доступен непосредственно конечным клиентам. Он может представлять из себя веб-сайт или просто API для сторонних разработчиков.
На внешнем слое мы НЕ предоставляем такую гибкость, как на внутреннем, а только даем доступ к базовым возможностям: основной параметр запроса, отступ, количество и т.п. Причем всё это с ограничениями.
Отчасти он является прокси до внутреннего API с рядом важных дополнений.
Вместо «. » делаем необходимые проверки прав, модифицируем запрос, определяем формат. Данные возвращаются в том же формате и тем же путем, как были запрошены.
Т.е. для http и json данные так и вернутся. Для socket и xml ответ будет через сокет и в xml.
Таким образом мы можем полностью контролировать, что доступно извне, как, на каких условиях и так далее.
Оптимизация тяжелых запросов
До этого мы описывали работу с базой максимально абстрактно, и, само собой, подобные запросы будут выполняться значительно медленнее оптимизированных. С первым шагом мы обнаруживаем (с помощью профайлера, либо другим удобным вам способом), что какой-то из запросов работает медленно.
Допустим, мы обратили внимание, что медленно работает запрос, в котором выбирается трек вместе с информацией об альбоме и музыканте. Для оптимизации нам понадобится создать новый внутренний метод:
и меняем вызов на внешнем слое ко внутреннему на представленный. Всё. Для конечного клиента ничего не поменялось, и кэш, и пути, и получаемые данные — те же, но вот работать всё стало быстрее.
Пользователи
Основная задача при работе с пользователями — проверять их права.
Как только пользователь авторизуется (способ не важен: куки, ключ, другой вариант), мы делаем один запрос к внутреннему слою, удостоверяя личность и получая разрешения. Далее проверки мы будем делать на внешнем слое.
Масштабирование
Большие преимущества мы получаем именно на этапе масштабирования.
И внешний и внутренний слой API мы можем запускать в любом количестве экземпляров, разруливая нагрузку с помощью балансеров. За счет подобного разделения мы можем запустить множество приложений с внешним слоем максимально близко к конечному клиенту, получив собственную CDN сеть с кэшированием данных.
Базы данных расширяются классическими способами, зависящими от задачи.
Кэширование
Для внутреннего слоя мы кэшируем результаты запросов к базам данных, а на внешнем — результаты, полученные от внутреннего слоя. У конечного клиента тоже может быть кэширование.
В одном из предыдущих примеров была строка «cache: 1800» — она может предоставить кэш как на внешнем слое, запоминая результат на сервере на полчаса, так и на клиенте, сложив результат, например в localStorage (ну или другое хранилище клиента).
Версионирование
Организовать файлы и поддержку разных версий можно несколькими путями, например:
1. Сделать папки v1, v2 и поместить в них весь относящийся к ним код. При модификации одной из версий API другая не затрагивается.
2. Различные репозитории, функционируют как различные приложения.
Буду рад добавить в статью дополнительные разделы по вашему запросу.
Также, если хотите уточнить где-то код — напишу и приложу, спрашивайте.
Возможно, это начало большого цикла статей на различные темы (или начало уже было положено). Материала накопилось очень много, но он не систематизирован.
Я хочу создать полноценный курс по разработке веб проектов. Прямо с нуля и до full-stack.
По планам он будет включать: видеолекции + текстовые уроки, домашние задания, самостоятельные проекты, работу с ментором, различные интенсивы, кучу кода (в формате запуска/доработки онлайн) и так далее. В качестве особенности хочу сделать «сетевой» формат, а не последовательный. Т.е. после прохождения определённых тем открываются другие, и ученик может сам выбирать, что его интересует в данный момент. По предварительным оценкам длительность обучения будет в районе полугода полноценных занятий по паре часов в день.
Понятно, что подобный проект реализуется не так быстро. Потому подойти к его разработке я хочу именно с привлечения партнёра, на чьей базе его можно будет реализовывать / продавать. Т.к. если сопутствующие вопросы я возьму на себя, то срок реализации станет совсем запредельным. Ну и плюс у разных порталов различный инструментарий, который я хочу учесть.
Я уже писал ряду проектов типа coursera с описанием своей затеи, но не получил никаких ответов. Причем, что обидно, вообще никаких, даже отказов.
Рынок изучал и уверен, что то, что реализую, более чем конкурентоспособно.
Буду рад любым предложениям о партнёрстве или советам, к кому следует обратиться.