Pull to refresh

Comments 13

Я пропустил момент, когда под API в техническом контексте стало пониматься только Web API
Когда это случилось?

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

А я не понял про миграцию БД - откуда она взялась?

Да, большое спасибо за уточнение! Касаемо миграций БД:
В разделе про путь разработки я описывал шаги от проектирования ER-диаграммы к релизу конечной точки API. Прежде чем работать с данными и возвращать их через API необходимо создать саму базу данных, с чем собственно и помогают миграции. В контексте Laravel они представляют собой что-то вроде системы контроля версий, позволяющей определять схемы БД приложения и управлять таблицами.

Вот именно - создать БД. А где тут миграция(и)?

Под миграциями в данном контексте подразумевается набор инструкций, определяющих изменения, которые мы хотим внести в схему базы данных. Создается набор файлов, в которых описывается, что конкретно нужно выполнить. Например, мы можем создать миграцию CreateUsersTable, в которой укажем, что при запуске миграции нужно создать таблицу users с определенными полями, а при откате миграции - удалить таблицу. И дальше можно будет при помощи команд php artisan migrate и php artisan migrate:rollback изменять базу данных в соответствии с определенными нами правилами

Ок, но странное название. Обычно миграция - это полный перенос базы с одного типа/вендора БД на другой.

В бэкенд фреймворках это уже свой устоявшийся термин - миграция это апдейт (скрипт апдейта) схемы БД при ее изменении в процессе разработки.

Вы правы, API применяется совершенно в различных областях (API операционных систем, библиотек, графические API и т.д.). Акцент статьи направлен на Web API в силу их распространенности и важности в современных ИТ-решениях. Думаю, что я сделал слишком резкий переход от общего к частному, из-за чего сложилось такое ощущение недосказанности. Но в любом случае спасибо, что подметили, поработаю над этим!

Ну, ежели вы в экосистеме PHP и вам нужно быстро спрототипировать Rest API - то API Platform ваш выбор. Там из коробки есть вообще всё и оно всё соответствует стандартам написания REST API. Зачем еще что-то своё городить?

А так, как выше верно сказали, API - не обязательно про веб. Формально любой интерфейс - это API. Потому что описывает набор публичных методов класса, реализующего этот интерфейс.

Думаю, что его выбор во многом зависит от требований конкретного проекта. Возможно по определенным критериям получится обойти альтернативные варианты. Но да, абсолютно согласен, что API Platform действительно достоен внимания, хоть на него не так часто обращается внимание в статьях/рейтингах/опросах.
А касаемо API и Web API - да, свою ошибку, вводящую в заблуждение, понял ;) Буду исправляться!

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

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

Я к чему, раз статья для новичков, было бы правильнее использовать термин бэкэнд. Эта тема у вас раскрыта. API - это отдельная широкая тема.

Спасибо за конструктивный комментарий! Соглашусь с замечанием, что API и бэкенд - две крупные темы, которым можно посвятить отдельные обсуждения, но тем не менее они тесно связаны. В контексте статьи я стремился преподнести концепцию API (в частности Web API, но, как я уже понял, с переходом у меня получилось не очень) и немного углубиться в подробности разработки, как раз таки связанные с серверной частью. Но думаю, что действительно можно было бы провести более четкое разграничение между API и бэкенодм, берущим на себя ответственность за процессы на стороне сервера, бизнес-логику, обработку данных, хранение и аутентификацию.

Sign up to leave a comment.