Comments 116
А зачем вообще REST API в этом случае?
REST API и веб приложение одно и то же, это основная идея.
Просто есть специальные GET запросы, которые возвращают статический html(это просто каркас из html и подключенных js/css файлов).
Динамические куски html собираются через запросы к этому жe API.
Запросы отсылают js компоненты, они же рендерят из полученных данных куски html и вставляют их в нужный контейнер.
В итоге пользователь видит готовую страницу с данными.
Вот и весь подход, если что то не понятно — задавайте вопросы )
B более того web приложение это и есть REST API. Если где то было описано в 2005 году, именно такой способ организации целого приложения, то ссылочку я почитаю)
AJAX это не имеет особого отношения к этому, можно и через web socket API сделать то же самое))
Но web socket мы тоже не затрагиваем.
Потому что это все просто способы передачи данных и не более.
REST API и веб приложение одно и то же, это основная идея.
И это плохая идея. У REST API общего назначения и у веб-приложения может быть много различий (вплоть до разных технологий). Зачем смешивать их в одну кучу?
Если мне нужно веб-приложение — я могу написать просто веб-приложение, зачем мне еще REST API городить? Если мне нужно REST API кроме как для веб-приложения — зачем мне их связывать?
На самом деле идея SPA растет из одной большой идеи — держать общее API для взаимодействия нескольких платформ, например одно и тоже API может использоваться SPA, iOS App, Android App и иметь какой-нибудь SOAP-фасад для Delphi или других интеграций.
Если вы почитаете описания многих фреймворков, то обратите внимание на их модульность и возможность комбинирования компонентов. Совсем не обязательно создавать одно большое SPA, иногда его можно разделить на несколько более мелких частей.
Ага, что-то вообще не понял революционности. У нас, например, такой многостраничник на нокауте:
Автор, мы уже используем все преимущества вашего подхода?
Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Нужно разработать приложение, которое будет работать через это API, оно мега сложное и имеет кучу страниц и логики.
Вы можете только UI интерфейс сделать на клиенте. Всякие CURL использовать не желательно, так как лучше чтобы нагрузка была в браузере через запросы напрямую к API.
Как вы сделаете его??
Суть статьи — что SPA не серебряная пуля и могут быть другие подходы к организации web приложения.
Приложение по большей часте строилось на back-end и лишь некоторые части использовали AJAX.
И этот подход до сих пор использовался. Затем с ростом популярности мобильных приложений появился SPA, так как заказчики поняли, что писать приложение, а потом еще и API затратно и несет проблемы в поддержке.
И больше ничего не было придумано…
и подход до сих пор используется. и на сервере странички рендерят. и на клиенте. и часть на сервере, а часть на клиенте — это всем известные способы известные уже много лет.
Закзчики чаще всего не понимают что такое API, AJAX и т.д.
То что частично работает через AJAX это не считается ;-)
Как вы реализуете все это?
Будите писать отдельно web приложение и отдельно API?
Скорее всего выберите SPA. Альтернативы сегодня я не видел чтобы было где то описано, если вы видели просьба поделиться источниками.
AJAX или что то другое — это просто способ передачи данных. Есть другие способы. Это не архитектура веб приложения, а способ передачи данных.
Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Если "API писали не мы, а другая компания", то оно замкнуто, и запихнуть туда еще какой-то html сравнительно сложно. Не говоря о том, что оно легко может быть в отдельном контролируемом окружении.
По сути предлагается несколько слабосвязанных SPA
Что-то вроде дробления на фронт-микросервисы/презентеры?
SPA имеет MVC и роутеры и все похожее что было на back-end.
MVC хороша для организации всего приложения и оно остается на back-end.
Тут лучше строить все на компонентах. Та идея js фреймворков (Angular, Backbone и другие) тут мало годиться.
Логика упрощается и много будет лишнего.
MVC хороша для организации всего приложения и оно остается на back-end.
Вот только у вас на бэк-энде не MVC, а REST API. В котором MVC избыточен.
REST API — содержит роутер(URL), контроллер, модель данных, а вьюха она используется только для тех запросов, которое возвращает статический html.
Еще раз html не содержит данных, не содержит никакой js логики. Всю логику интерфейса и обработку данных делают js компоненты или другие штуки, которые подключены к этой статической странице.
JS получают данные из той же API. И получается что API и веб приложение это одно и тоже.
REST API — содержит роутер(URL), контроллер, модель данных, а вьюха она используется только для тех запросов, которое возвращает статический html.
Статический html не является частью REST API. Поэтому никого V в вашем мифическом серверном MVC нет. Без V это не presentation pattern.
Еще раз html не содержит данных, не содержит никакой js логики. Всю логику интерфейса и обработку данных делают js компоненты или другие штуки, которые подключены к этой статической странице.
И откуда же берутся эти компоненты? Материализуются магически, или все-таки передаются в рамках той же страницы с сервера?
А почему REST API не может html возвращать? Чем данные html отличаются от JSON например или XML??
Это просто данные.
Ресурсы конечно не являются частью REST API))
Файлик не сложно же подключить??
Не сложно. Но в этот момент ваше утверждение "html не содержит никакой js-логики" становится ложным.
А почему REST API не может html возвращать?
Потому что это противоречит концепции REST API.
«Потому что это противоречит концепции REST API.» — это почему это??
REST API может возвращать все что угодно, JSON,HTML, Картинки, фидео, аудео — все что угодно.
Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.
Это то же самое. Нет никакой разницы между тем, включили вы js-код в страницу напрямую или через src
.
это почему это??
Потому что вы нарушаете принцип единой ответственности. REST API отвечает за программное взаимодействие с системой, а HTML — это часть веб-приложения.
На сегодняшний день описано только 2-ва подхода к разработке web приложений:
1. Мультистраничное приложение, когда интерфейс строиться на back-end.
2. SPA — когда логика клиента полностью на стороне клиента (за исключением одной страницы ). Использовать SPA подход на нескольких страницах это уже не SPA, а извращение.
3. Есть еще варианты? Тогда скажите название этого(их) подходов и их описание??
Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название, а не ваши абстракции.
Один разработчик скажет «Я знаю способ, это способ SPA», а другой скажет «я знаю… а названия не могу сказать.»
Руководитель спросит, а как найти доку к нему, если оно даже названия не имеет??
Есть мультистраничное приложение (multipage application), которое идет еще с появления интернета и генераторов HTML (PHP например) и SPA.
Эти подходы имеют свое название, они описаны и про них можно прочитать.
Этот подход вообще родился на практике, и мне он понравился. Очень удобно.
Многие не прочитали даже до конца и не поняли сути, судя по комментариям. Так прочитайте и поймете идею от и до)
Если вы решили так делать, то это уже задача.
Суть то не в том. Как вы это сделаете если вы решили так сделать?
Я написал какие аргументы есть, как это работает.
А в ответ вижу размышления про пуговицы, задачи или не задачи...))
На сегодняшний день описано только 2-ва подхода к разработке web приложений
Вот в этом-то и проблема, что эти способы не взаимоисключающие, их можно комбинировать в любых пропорциях, следовательно их гораздо больше 2-х.
Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название
"Тонкий клиент" это называется.
Во-первых, уже фактически стандарт если вы пишите приложение, то оно должно быть как минимум на мобильных устройствах. Сейчас очень много приложений пишутся по принципу «один сервер — много клиентов». Реализуется это как раз через REST API.
А чтобы написать web клиент есть только одна архитектура SPA. Она имеет название и описана.
Во-вторых, SPA имеет минусы и я их описал в статье. Кто не согласен с этим используйте SPA. Кому что нравиться.
Но что остается если вам не нравится SPA или может есть способы сделать проще и лучше?
Я повторюсь, это способ родился на практике. Я пишу приложения быстрее через этот способ чем SPA.
Каждая страница может работать самостоятельно, использовать разные технологии, не быть прибитым гвоздями к js фреймворку.
Вместо того чтобы спорить, предлагаю обсудить именно этот подход, как это работает и как можно улучшить подход.
Звучит как велосипед, но и SPA был когда то велосипедом и все было когда то — в начале.
Тут дело вкуса. Я не пытаюсь очернить SPA, просто ничего идеального нет.
Можно строить приложения любой сложности на этой архитектуре. И я скажу что это проще монолитного SPA, если нет дайте аргументы.
Нет жесткой привязки к MVC фреймворку на fron-end. Тут не нужны страницы, не нужны роутеры и MVC по сути не особо то нужно.
Приложение MVC на front-end это монолит, по сути одно приложение, которое может сломаться если есть ошибка в каком то js файле. Поэтому SPA как правило жестко тестируется.
Back-end это просто API, которое кроме CRUD дополнительно отсылает статические html (просто html каркасы). Back-end тоже немного упрощается.
И вообще речь не обо мне.
Давайте обсудим аргументированно этот подход. Если что то было раньше — то я только за, но если это имеет документацию и есть примеры.
Вот Angular я выбрал и все роутеры только в нем, и все на нем завязано. Или вы сделаете 2 html страницы, на одной Angular, а на другой Backbone и каждый свои роутеры делает??
В том то дело что SPA это слишком монолитное приложение, перейти к другой технологии — значит переписывать все приложение. А это печально.
0. Пожалуйста пишите тесты какие вздумается.
1. Роутинг на стороне сервера.
2. Валидация через js компоненты на стороне клиента и на стороне сервера на уровне моделей. Все стандартно.
3. Темлейты на стороне клиента.
4. Через запросы на стороне клиента, например в js компоненте.
5. Можно подключать на разных страницах одинаковые компоненты. Если ООП то можно модифицировать. Все зависит от задач, повторное использование компонентов так же реально.
6. На стороне клиента.
смысл в том что вы динамически подгружаете контент, не важно как.
важен факт.
я подобный сайт писал лет 6 так назад, когда еще ничерта не знал.
сайт отлично работал и на JS, и при выключенном JS.
(+ еще History API и пользователь всегда мог взять URL и увидеть тоже самое)
тут нет никакого новаторства.
насчет AJAX, тогда не было иного толкового способа динамические запросы делать, потому и говорят про него.
ваш способ полностью аналогичен тому что был 10 лет назад, детали тут в нюансах.
тогда не было таких моднявых слов как REST API, тогда просто делали.
Почитайте про веб-компоненты и html-импорты. Ну и в списке минусов SPA согласиться с натяжкой можно только с 4-м пунктом, остальное — детский сад, уж простите.
Статься не для критики SPA )
Дело не в том, что устраивает, а в том, что строить решения на основе неверных предпосылок — есть инженерный фейл. И я утверждаю, что указанные предпосылки — неверны.
И я не зря написал про веб-компоненты, они позволяют комбинировать SPA c неSPA в вашем фронтэнде в любых пропорциях.
Компоненты тут не причем. Есть либо одна страница с сервера(Тогда это SPA) или несколько, но это уже что то другое.
SPA — одностраничное приложение дословно
да, SPA — это то, что позволяет работать с динамически обновляемыми данными без перезагрузки страницы-контейнера. Но страница !== приложение, строго говоря. Вы можете на сгенерированной сервером странице иметь виджет со своей сложной внутренней логикой, влияющей на свое окружение. Вы можете перегружать такие страницы отдельно от этого виждета и это будет комбинированным подходом. Вы можете воспринимать сгенерированный html как данные, либо как контейнер для вашего SPA, в соответсвии с вашими задачами, разбивая все приложение на разделы и модули как вам угодно. И компоненты — это то, что позволяет все это делать с легкостью, они еще как причем.
Суть проблемы что есть API и как нам сделать веб приложение через это API.
Это можно через SPA сделать, но можно и не через SPA.
И не понимаю что на меня так набросились. Я же не говорю что SPA это плохо, а предложил вариант как можно написать приложение на API без использования SPA, MVC и прочих штук на front-end.
Без каких прочих штук? Вы сами пишите, что js, в предложеной вами архитектуре, работает с динамическими данными: "вся динамическая часть собирается javascript-ом на стороне клиента". Как это магическим образом исключает SPA, MVC и "прочие штуки"? А раздавать прочую статику сервера умеют давно, как это относится к вашей идее? Ваш API может возвращать что угодно, и голые данные и сврстанные, для чего есть куча устоявшихся методов, на что именно из этой экосистемы вы вглянули по новому?
Во-вторых, все работает через API.
Вы изобрели многостраничность и "не-SPA"? Или вы изобрели API? Или вы просто издеваетесь? Вот знаете, я могу допустить, что в ваших идеях, возможно, есть какое-то рациональное зерно, возможно просто вы не можете подобрать правильные слова для их описания, но на данный момент, выглядит все это более чем сомнительно, мягко говоря.
API для того и существует чтобы предоставлять данные для ЛЮБОГО интерфейса, и HTML-клиент лишь один из нескольких возможных. Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?
По сути и шаблонизаторы на сервере не нужны, потому что там шаблонов нет. Возвращается каркас html без данных вообще.
Максимум можно комбинировать кусок с header и footer и статичный кусок страницы, это можно даже include обычным сделать.
Больше логики html никакой на back-end нету.
Они то всю динамику и логику интерфейса и делают.
То есть можно сделать компонент, шаблонизатор для него и в перед. И страница будет вообще работать как отдельное приложение. Каждая страница сервиса!
Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.
На эту же страницу ставятся js компоненты или другие штуки, они то всю динамику и логику интерфейса и делают.
А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)
Вот и все.
«Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.»
Можете, но это уже не API. Вы просто выдаете клиентские шаблоны для страниц.
«А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)»
Вы просто смешали чати приложения и API вместе, а потом говорите программисту «используй только эту часть, это true-API, а это чать веб-приложения». А потом вам понадобится дать доступ к API другим программистам, чтобы они на его основе сделали свое мобильное приложение и вы им выдадите вот это все. Они, конечно же, зададут вам вопросы «нафига нам html странички?», на что вы им скажете что это торчат части другого клиента и им их использовать не надо.
Пройдет время, вы захотите поменять свои веб-странички выдаваемые API и… в этот момент в комнату влетает разгневанный начальник/клиент/заказчик и кричит «верни все назад, у команды из Индии/Китая/Другой страны все рухнуло, это ты виноват!». И знаете, он будет прав, потому что кто-то из той команды программистов заиспользовал ваши html-шаблоны и теперь вы с ними связаны и не можете обновить ваш сайт.
А еще спустя какое-то время, вас попросят выкатить новую версию API, с немного другими шаблонами. И, вуа-ля, у вас уже три версии html-страничек: для старого API, нового API и вашего нового сайта.
А зачем мобильникам эти страницы ?)
Не используют и что. Даже если в страницах что то поменяется от этого ничего не измениться.
«Пройдет время, вы захотите поменять свои веб-странички выдаваемые API» — эти страницы часть веб клиента, в чем проблема если они поменяются?)
Но Бог с ним. Допустим мы вынесем из API html страницы.
Самое главное что веб приложение будет так же работать через REST API.
Да мало ли что взбредет в голову программистам, которым вы дадите это API. Может захотят сделать какие-то страницы внутри приложения на html.
Если в страницах (а это воспринимается как часть API) что-то изменится, то формально поменяется API.
“Самое главное что веб приложение будет так же работать через REST API.»
Вот об этом вам и говорят, что у вас просто веб-приложение работает через REST API, это не новый подход. Он давно практикуется в случаях, когда нужно чтобы на выходе и API было и приложение. И чтобы не писать для приложения отдельный back-end, его просто заменяют на API. А дальше, как правило, MVC-фреймворк на клиенте.
Сама разработка в таком случае строится на том, что параллельно с клиентской частью на html пишется API, которое просто выдает данные ничего не зная о специфике клиента. На стороне браузера, как правило, SPA, который просто с сервера подтягивает статичные шаблоны страниц и манипулирует ими. Вообще как устроен клиент, в данном случае не столь важно, т.к. к REST API можно прикрутить что угодно. Важно лишь то, что клиент отдельно, API отдельно.
Это штука только для веб интерфейса.
А затем вдруг часть состояния с одной страницы нужно передать на другую и начинается гемор с сохранением его куда-то и дальнейшим восстановлением. Через какое-то время приложение становиться достаточно сложным и гемор с постоянным сохранением/восстановлением начинает перекрывать все другие плюсы. Выкидываем всё сделанное, пишем нормальное SPA.
Можно примеры SPA сайтов? :)
SPA — не серебряная пуля, или альтернативный подход к web-разработке. Часть 1