Comments 116
А зачем вообще REST API в этом случае?
Заметил, что фраза «работает на API» вошла в число аргументов для заказчика в пользу качества сайта. Что-то типа приставки «нано-» или «нейро-».
Еще раз.
REST API и веб приложение одно и то же, это основная идея.
Просто есть специальные GET запросы, которые возвращают статический html(это просто каркас из html и подключенных js/css файлов).
Динамические куски html собираются через запросы к этому жe API.
Запросы отсылают js компоненты, они же рендерят из полученных данных куски html и вставляют их в нужный контейнер.
В итоге пользователь видит готовую страницу с данными.
Вот и весь подход, если что то не понятно — задавайте вопросы )
REST API и веб приложение одно и то же, это основная идея.
Просто есть специальные GET запросы, которые возвращают статический html(это просто каркас из html и подключенных js/css файлов).
Динамические куски html собираются через запросы к этому жe API.
Запросы отсылают js компоненты, они же рендерят из полученных данных куски html и вставляют их в нужный контейнер.
В итоге пользователь видит готовую страницу с данными.
Вот и весь подход, если что то не понятно — задавайте вопросы )
Так делали (и делают) сайты до «изобретения» SPA, фичу динамической погрузки контента называли новомодным словом AJAX, и это было прорывом по сравненению с изначальным способом построения страниц полностью на сервере. Вы сделали революционное открытие 2005-го года.
Я же говорю — полностью базируется на REST API.
B более того web приложение это и есть REST API. Если где то было описано в 2005 году, именно такой способ организации целого приложения, то ссылочку я почитаю)
AJAX это не имеет особого отношения к этому, можно и через web socket API сделать то же самое))
Но web socket мы тоже не затрагиваем.
Потому что это все просто способы передачи данных и не более.
B более того web приложение это и есть REST API. Если где то было описано в 2005 году, именно такой способ организации целого приложения, то ссылочку я почитаю)
AJAX это не имеет особого отношения к этому, можно и через web socket API сделать то же самое))
Но web socket мы тоже не затрагиваем.
Потому что это все просто способы передачи данных и не более.
REST API и веб приложение одно и то же, это основная идея.
И это плохая идея. У REST API общего назначения и у веб-приложения может быть много различий (вплоть до разных технологий). Зачем смешивать их в одну кучу?
Если мне нужно веб-приложение — я могу написать просто веб-приложение, зачем мне еще REST API городить? Если мне нужно REST API кроме как для веб-приложения — зачем мне их связывать?
Вы придумали «архитектуру», на которой уже базируется ~90% сайтов всего видимого интернета (т.е., «нехипстерская» его доля), и к которой толкает PHP «by design» (особенно без MVC-фреймворков, когда роутер — это файловая система и иногда плагин mod_rewrite).
Ваша идея очень похожа на rails-turbolinks gem.
На самом деле идея SPA растет из одной большой идеи — держать общее API для взаимодействия нескольких платформ, например одно и тоже API может использоваться SPA, iOS App, Android App и иметь какой-нибудь SOAP-фасад для Delphi или других интеграций.
Если вы почитаете описания многих фреймворков, то обратите внимание на их модульность и возможность комбинирования компонентов. Совсем не обязательно создавать одно большое SPA, иногда его можно разделить на несколько более мелких частей.
На самом деле идея SPA растет из одной большой идеи — держать общее API для взаимодействия нескольких платформ, например одно и тоже API может использоваться SPA, iOS App, Android App и иметь какой-нибудь SOAP-фасад для Delphi или других интеграций.
Если вы почитаете описания многих фреймворков, то обратите внимание на их модульность и возможность комбинирования компонентов. Совсем не обязательно создавать одно большое SPA, иногда его можно разделить на несколько более мелких частей.
Подождите. Я чего-то не понимаю. Это такая ирония? Но сегодня не пятница по календарю. В чем инновационность? Где она вообще? Почти все сайты так работают.
Ага, что-то вообще не понял революционности. У нас, например, такой многостраничник на нокауте:
Автор, мы уже используем все преимущества вашего подхода?
Вообще не то.
Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Нужно разработать приложение, которое будет работать через это API, оно мега сложное и имеет кучу страниц и логики.
Вы можете только UI интерфейс сделать на клиенте. Всякие CURL использовать не желательно, так как лучше чтобы нагрузка была в браузере через запросы напрямую к API.
Как вы сделаете его??
Суть статьи — что SPA не серебряная пуля и могут быть другие подходы к организации web приложения.
Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Нужно разработать приложение, которое будет работать через это API, оно мега сложное и имеет кучу страниц и логики.
Вы можете только UI интерфейс сделать на клиенте. Всякие CURL использовать не желательно, так как лучше чтобы нагрузка была в браузере через запросы напрямую к API.
Как вы сделаете его??
Суть статьи — что SPA не серебряная пуля и могут быть другие подходы к организации web приложения.
Также как делали лет 8 назад. Когда была модная аббревиатура AJAX. раз уж нельзя SPA использовать
Так как это называлось?
Приложение по большей часте строилось на back-end и лишь некоторые части использовали AJAX.
И этот подход до сих пор использовался. Затем с ростом популярности мобильных приложений появился SPA, так как заказчики поняли, что писать приложение, а потом еще и API затратно и несет проблемы в поддержке.
И больше ничего не было придумано…
Приложение по большей часте строилось на back-end и лишь некоторые части использовали AJAX.
И этот подход до сих пор использовался. Затем с ростом популярности мобильных приложений появился SPA, так как заказчики поняли, что писать приложение, а потом еще и API затратно и несет проблемы в поддержке.
И больше ничего не было придумано…
Без понятия, есть ли у этого вообще название.
и подход до сих пор используется. и на сервере странички рендерят. и на клиенте. и часть на сервере, а часть на клиенте — это всем известные способы известные уже много лет.
Закзчики чаще всего не понимают что такое API, AJAX и т.д.
и подход до сих пор используется. и на сервере странички рендерят. и на клиенте. и часть на сервере, а часть на клиенте — это всем известные способы известные уже много лет.
Закзчики чаще всего не понимают что такое API, AJAX и т.д.
Тут реализация ПОЛНОСТЬЮ через REST API и в этом вся суть.
То что частично работает через AJAX это не считается ;-)
То что частично работает через AJAX это не считается ;-)
Считается. REST API не более чем стандартизация API. Не всегда разумно делать полностью API. Где было разумно — люди делали. Да, в далеком 2005.
Вот задача. Есть мобильные приложения, есть web приложение.
Как вы реализуете все это?
Будите писать отдельно web приложение и отдельно API?
Скорее всего выберите SPA. Альтернативы сегодня я не видел чтобы было где то описано, если вы видели просьба поделиться источниками.
AJAX или что то другое — это просто способ передачи данных. Есть другие способы. Это не архитектура веб приложения, а способ передачи данных.
Как вы реализуете все это?
Будите писать отдельно web приложение и отдельно API?
Скорее всего выберите SPA. Альтернативы сегодня я не видел чтобы было где то описано, если вы видели просьба поделиться источниками.
AJAX или что то другое — это просто способ передачи данных. Есть другие способы. Это не архитектура веб приложения, а способ передачи данных.
Я скажу проще — у вас есть API, причем писали его не вы, а другая компания.
Если "API писали не мы, а другая компания", то оно замкнуто, и запихнуть туда еще какой-то html сравнительно сложно. Не говоря о том, что оно легко может быть в отдельном контролируемом окружении.
UFO just landed and posted this here
Какая то странная маленькая статья, которая существует по непонятным причинам.
По сути предлагается несколько слабосвязанных SPA — грубо по одному на каждую коллекцию/корень агрегата? По-моему, минусов больше чем плюсов, если страницы плюс-минус имеют одинаковые раскладки, логику и т.п. Разве что совсем разные технологии используются.
По сути предлагается несколько слабосвязанных SPA
Что-то вроде дробления на фронт-микросервисы/презентеры?
Не совсем.
SPA имеет MVC и роутеры и все похожее что было на back-end.
MVC хороша для организации всего приложения и оно остается на back-end.
Тут лучше строить все на компонентах. Та идея js фреймворков (Angular, Backbone и другие) тут мало годиться.
Логика упрощается и много будет лишнего.
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 не содержит данных, не содержит никакой 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))
А почему REST API не может html возвращать? Чем данные html отличаются от JSON например или XML??
Это просто данные.
Ресурсы конечно не являются частью REST API))
Файлик не сложно же подключить??
Не сложно. Но в этот момент ваше утверждение "html не содержит никакой js-логики" становится ложным.
А почему REST API не может html возвращать?
Потому что это противоречит концепции REST API.
Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.
«Потому что это противоречит концепции REST API.» — это почему это??
REST API может возвращать все что угодно, JSON,HTML, Картинки, фидео, аудео — все что угодно.
«Потому что это противоречит концепции REST API.» — это почему это??
REST API может возвращать все что угодно, JSON,HTML, Картинки, фидео, аудео — все что угодно.
Html же не содержит никакой логики. Это уже ресурсы страницы содержат, а это другое.
Это то же самое. Нет никакой разницы между тем, включили вы js-код в страницу напрямую или через src.
это почему это??
Потому что вы нарушаете принцип единой ответственности. REST API отвечает за программное взаимодействие с системой, а HTML — это часть веб-приложения.
.
Напоминает ситуацию, когда начинающий разработчик сделал какое-то «мега крутое» открытие — придумал подход к разработке или архитекруту приложения (и он в это верит), а на самом деле просто не дочитал доки.
Введение к статье я вижу, а где она сама-то?
Ребята вот есть задача сделать API на котором работают несколько клиентов — это web, мобильные приложения и так далее.
На сегодняшний день описано только 2-ва подхода к разработке web приложений:
1. Мультистраничное приложение, когда интерфейс строиться на back-end.
2. SPA — когда логика клиента полностью на стороне клиента (за исключением одной страницы ). Использовать SPA подход на нескольких страницах это уже не SPA, а извращение.
3. Есть еще варианты? Тогда скажите название этого(их) подходов и их описание??
Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название, а не ваши абстракции.
На сегодняшний день описано только 2-ва подхода к разработке web приложений:
1. Мультистраничное приложение, когда интерфейс строиться на back-end.
2. SPA — когда логика клиента полностью на стороне клиента (за исключением одной страницы ). Использовать SPA подход на нескольких страницах это уже не SPA, а извращение.
3. Есть еще варианты? Тогда скажите название этого(их) подходов и их описание??
Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название, а не ваши абстракции.
Не всегда требуются названия. Вы как застёгиваете пуговицы на рубашке? Есть ли у этого способа название? Какие ещё существуют архитектурные паттерны для процесса застёгивания пуговиц? Вот и ваш newDHTML — это будто вы научились застёгивать пуговицы и решили дать этому название. Пуговицы придуманы для того, чтобы их продевали в петельки для удержания двух краёв одежды. И это не моё изобретение, это изначальное предназначение пуговиц. Но предлагаю назвать этот паттерн PugoFlow, чтобы отличать его от шнурования или застёгивания липучек.
Вот представьте — задача сделать приложение на REST API.
Один разработчик скажет «Я знаю способ, это способ SPA», а другой скажет «я знаю… а названия не могу сказать.»
Руководитель спросит, а как найти доку к нему, если оно даже названия не имеет??
Есть мультистраничное приложение (multipage application), которое идет еще с появления интернета и генераторов HTML (PHP например) и SPA.
Эти подходы имеют свое название, они описаны и про них можно прочитать.
Этот подход вообще родился на практике, и мне он понравился. Очень удобно.
Многие не прочитали даже до конца и не поняли сути, судя по комментариям. Так прочитайте и поймете идею от и до)
Один разработчик скажет «Я знаю способ, это способ SPA», а другой скажет «я знаю… а названия не могу сказать.»
Руководитель спросит, а как найти доку к нему, если оно даже названия не имеет??
Есть мультистраничное приложение (multipage application), которое идет еще с появления интернета и генераторов HTML (PHP например) и SPA.
Эти подходы имеют свое название, они описаны и про них можно прочитать.
Этот подход вообще родился на практике, и мне он понравился. Очень удобно.
Многие не прочитали даже до конца и не поняли сути, судя по комментариям. Так прочитайте и поймете идею от и до)
UFO just landed and posted this here
Вам ставит ее тимлид или вы сами понимаете что это оптимальный способ. НЕ важно.
Если вы решили так делать, то это уже задача.
Суть то не в том. Как вы это сделаете если вы решили так сделать?
Если вы решили так делать, то это уже задача.
Суть то не в том. Как вы это сделаете если вы решили так сделать?
На сегодняшний день описано только 2-ва подхода к разработке web приложений
Вот в этом-то и проблема, что эти способы не взаимоисключающие, их можно комбинировать в любых пропорциях, следовательно их гораздо больше 2-х.
UFO just landed and posted this here
Так каким образом вы сделаете приложение так чтобы оно полностью базировалось на API??
Я имею в виду архитектурный подход, который имеет название
"Тонкий клиент" это называется.
3. DHTML+AJAX — больше десятилетия уже в массах. По сути, SPA — это лишь вырожденный случай DHTML+AJAX приложения. Вы где были последние лет 10, что пропустили как зарождались SPA? )
Автор, выкладывай todo-app, чтоб было видно, в чем новаторство подхода.
Для чего это все.
Во-первых, уже фактически стандарт если вы пишите приложение, то оно должно быть как минимум на мобильных устройствах. Сейчас очень много приложений пишутся по принципу «один сервер — много клиентов». Реализуется это как раз через REST API.
А чтобы написать web клиент есть только одна архитектура SPA. Она имеет название и описана.
Во-вторых, SPA имеет минусы и я их описал в статье. Кто не согласен с этим используйте SPA. Кому что нравиться.
Но что остается если вам не нравится SPA или может есть способы сделать проще и лучше?
Я повторюсь, это способ родился на практике. Я пишу приложения быстрее через этот способ чем SPA.
Каждая страница может работать самостоятельно, использовать разные технологии, не быть прибитым гвоздями к js фреймворку.
Вместо того чтобы спорить, предлагаю обсудить именно этот подход, как это работает и как можно улучшить подход.
Звучит как велосипед, но и SPA был когда то велосипедом и все было когда то — в начале.
Во-первых, уже фактически стандарт если вы пишите приложение, то оно должно быть как минимум на мобильных устройствах. Сейчас очень много приложений пишутся по принципу «один сервер — много клиентов». Реализуется это как раз через REST API.
А чтобы написать web клиент есть только одна архитектура SPA. Она имеет название и описана.
Во-вторых, SPA имеет минусы и я их описал в статье. Кто не согласен с этим используйте SPA. Кому что нравиться.
Но что остается если вам не нравится SPA или может есть способы сделать проще и лучше?
Я повторюсь, это способ родился на практике. Я пишу приложения быстрее через этот способ чем SPA.
Каждая страница может работать самостоятельно, использовать разные технологии, не быть прибитым гвоздями к js фреймворку.
Вместо того чтобы спорить, предлагаю обсудить именно этот подход, как это работает и как можно улучшить подход.
Звучит как велосипед, но и SPA был когда то велосипедом и все было когда то — в начале.
UFO just landed and posted this here
Может быть)
Тут дело вкуса. Я не пытаюсь очернить SPA, просто ничего идеального нет.
Можно строить приложения любой сложности на этой архитектуре. И я скажу что это проще монолитного SPA, если нет дайте аргументы.
Нет жесткой привязки к MVC фреймворку на fron-end. Тут не нужны страницы, не нужны роутеры и MVC по сути не особо то нужно.
Приложение MVC на front-end это монолит, по сути одно приложение, которое может сломаться если есть ошибка в каком то js файле. Поэтому SPA как правило жестко тестируется.
Back-end это просто API, которое кроме CRUD дополнительно отсылает статические html (просто html каркасы). Back-end тоже немного упрощается.
И вообще речь не обо мне.
Давайте обсудим аргументированно этот подход. Если что то было раньше — то я только за, но если это имеет документацию и есть примеры.
Тут дело вкуса. Я не пытаюсь очернить SPA, просто ничего идеального нет.
Можно строить приложения любой сложности на этой архитектуре. И я скажу что это проще монолитного SPA, если нет дайте аргументы.
Нет жесткой привязки к MVC фреймворку на fron-end. Тут не нужны страницы, не нужны роутеры и MVC по сути не особо то нужно.
Приложение MVC на front-end это монолит, по сути одно приложение, которое может сломаться если есть ошибка в каком то js файле. Поэтому SPA как правило жестко тестируется.
Back-end это просто API, которое кроме CRUD дополнительно отсылает статические html (просто html каркасы). Back-end тоже немного упрощается.
И вообще речь не обо мне.
Давайте обсудим аргументированно этот подход. Если что то было раньше — то я только за, но если это имеет документацию и есть примеры.
UFO just landed and posted this here
А могу я используя SPA использовать несколько фреймворков?
Вот Angular я выбрал и все роутеры только в нем, и все на нем завязано. Или вы сделаете 2 html страницы, на одной Angular, а на другой Backbone и каждый свои роутеры делает??
В том то дело что SPA это слишком монолитное приложение, перейти к другой технологии — значит переписывать все приложение. А это печально.
0. Пожалуйста пишите тесты какие вздумается.
1. Роутинг на стороне сервера.
2. Валидация через js компоненты на стороне клиента и на стороне сервера на уровне моделей. Все стандартно.
3. Темлейты на стороне клиента.
4. Через запросы на стороне клиента, например в js компоненте.
5. Можно подключать на разных страницах одинаковые компоненты. Если ООП то можно модифицировать. Все зависит от задач, повторное использование компонентов так же реально.
6. На стороне клиента.
Вот Angular я выбрал и все роутеры только в нем, и все на нем завязано. Или вы сделаете 2 html страницы, на одной Angular, а на другой Backbone и каждый свои роутеры делает??
В том то дело что SPA это слишком монолитное приложение, перейти к другой технологии — значит переписывать все приложение. А это печально.
0. Пожалуйста пишите тесты какие вздумается.
1. Роутинг на стороне сервера.
2. Валидация через js компоненты на стороне клиента и на стороне сервера на уровне моделей. Все стандартно.
3. Темлейты на стороне клиента.
4. Через запросы на стороне клиента, например в js компоненте.
5. Можно подключать на разных страницах одинаковые компоненты. Если ООП то можно модифицировать. Все зависит от задач, повторное использование компонентов так же реально.
6. На стороне клиента.
UFO just landed and posted this here
Все было когда то «велосипедом».
Верно, и в данном случае «когда-то» — это в 2005-ом.
Опять про AJAX да?)))
Про newDHTML, если вам так больше нравится.
да хоть AJAX, хоть не AJAX.
смысл в том что вы динамически подгружаете контент, не важно как.
важен факт.
я подобный сайт писал лет 6 так назад, когда еще ничерта не знал.
сайт отлично работал и на JS, и при выключенном JS.
(+ еще History API и пользователь всегда мог взять URL и увидеть тоже самое)
тут нет никакого новаторства.
насчет AJAX, тогда не было иного толкового способа динамические запросы делать, потому и говорят про него.
ваш способ полностью аналогичен тому что был 10 лет назад, детали тут в нюансах.
тогда не было таких моднявых слов как REST API, тогда просто делали.
смысл в том что вы динамически подгружаете контент, не важно как.
важен факт.
я подобный сайт писал лет 6 так назад, когда еще ничерта не знал.
сайт отлично работал и на JS, и при выключенном JS.
(+ еще History API и пользователь всегда мог взять URL и увидеть тоже самое)
тут нет никакого новаторства.
насчет AJAX, тогда не было иного толкового способа динамические запросы делать, потому и говорят про него.
ваш способ полностью аналогичен тому что был 10 лет назад, детали тут в нюансах.
тогда не было таких моднявых слов как REST API, тогда просто делали.
UFO just landed and posted this here
Почитайте про веб-компоненты и html-импорты. Ну и в списке минусов SPA согласиться с натяжкой можно только с 4-м пунктом, остальное — детский сад, уж простите.
UFO just landed and posted this here
Если устраивает SPA — то круто.
Статься не для критики SPA )
Статься не для критики SPA )
Дело не в том, что устраивает, а в том, что строить решения на основе неверных предпосылок — есть инженерный фейл. И я утверждаю, что указанные предпосылки — неверны.
И я не зря написал про веб-компоненты, они позволяют комбинировать SPA c неSPA в вашем фронтэнде в любых пропорциях.
SPA — одностраничное приложение дословно. Все что имеет несколько страниц с сервера это уже не SPA.
Компоненты тут не причем. Есть либо одна страница с сервера(Тогда это SPA) или несколько, но это уже что то другое.
Компоненты тут не причем. Есть либо одна страница с сервера(Тогда это SPA) или несколько, но это уже что то другое.
Не все аббревиатуры в ИТ (и, уверен, в других областях) несут смысл только лишь дословно содержащийся в буквах этой аббревиатуры. Не все технологии можно изучить лишь по их названию. Ограничение «если два SPA на одном адресе, то это уже не SPA» с практической стороны не несёт особого смысла, но может использоваться, наверное, в суде.
извините, то есть для того чтоб быть SPA обязательно должен быть лишь один URL?
SPA — одностраничное приложение дословно
да, SPA — это то, что позволяет работать с динамически обновляемыми данными без перезагрузки страницы-контейнера. Но страница !== приложение, строго говоря. Вы можете на сгенерированной сервером странице иметь виджет со своей сложной внутренней логикой, влияющей на свое окружение. Вы можете перегружать такие страницы отдельно от этого виждета и это будет комбинированным подходом. Вы можете воспринимать сгенерированный html как данные, либо как контейнер для вашего SPA, в соответсвии с вашими задачами, разбивая все приложение на разделы и модули как вам угодно. И компоненты — это то, что позволяет все это делать с легкостью, они еще как причем.
Всем понятно что такое SPA. Можно что то по своему делать, да.
Суть проблемы что есть API и как нам сделать веб приложение через это API.
Это можно через SPA сделать, но можно и не через SPA.
И не понимаю что на меня так набросились. Я же не говорю что SPA это плохо, а предложил вариант как можно написать приложение на API без использования SPA, MVC и прочих штук на front-end.
Суть проблемы что есть API и как нам сделать веб приложение через это API.
Это можно через SPA сделать, но можно и не через SPA.
И не понимаю что на меня так набросились. Я же не говорю что SPA это плохо, а предложил вариант как можно написать приложение на API без использования SPA, MVC и прочих штук на front-end.
Без каких прочих штук? Вы сами пишите, что js, в предложеной вами архитектуре, работает с динамическими данными: "вся динамическая часть собирается javascript-ом на стороне клиента". Как это магическим образом исключает SPA, MVC и "прочие штуки"? А раздавать прочую статику сервера умеют давно, как это относится к вашей идее? Ваш API может возвращать что угодно, и голые данные и сврстанные, для чего есть куча устоявшихся методов, на что именно из этой экосистемы вы вглянули по новому?
Во-первых. Тут многоcтраничность и это не SPA.
Во-вторых, все работает через API.
Во-вторых, все работает через API.
Вы изобрели многостраничность и "не-SPA"? Или вы изобрели API? Или вы просто издеваетесь? Вот знаете, я могу допустить, что в ваших идеях, возможно, есть какое-то рациональное зерно, возможно просто вы не можете подобрать правильные слова для их описания, но на данный момент, выглядит все это более чем сомнительно, мягко говоря.
Набросились на вас за резонёрство, за попытку создания альтернативной терминологии без практической на то необходимости, за выдумывание теоретических проблем, не существующих на практике.
Непонимаю. Автор взял API реализовал для него клиента на HTML и назвал это новым подходом? Статичные шаблоны возвращаются по запросу с сервера API, а не с сервера клиента. Таким образом смешали логику и шаблоны клиента, что вообще не очень хорошо. Раз уж делаете API, то вынесите его на один адрес, а шаблоны, скрипты и стили клиента на другой. Тут, по-моему, не новый подход к разработке, а нарушение уже устоявшихся.
API для того и существует чтобы предоставлять данные для ЛЮБОГО интерфейса, и HTML-клиент лишь один из нескольких возможных. Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?
API для того и существует чтобы предоставлять данные для ЛЮБОГО интерфейса, и HTML-клиент лишь один из нескольких возможных. Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?
«смешали логику и шаблоны клиента» — нету никакой логики шаблонов.
По сути и шаблонизаторы на сервере не нужны, потому что там шаблонов нет. Возвращается каркас html без данных вообще.
Максимум можно комбинировать кусок с header и footer и статичный кусок страницы, это можно даже include обычным сделать.
Больше логики html никакой на back-end нету.
По сути и шаблонизаторы на сервере не нужны, потому что там шаблонов нет. Возвращается каркас html без данных вообще.
Максимум можно комбинировать кусок с header и footer и статичный кусок страницы, это можно даже include обычным сделать.
Больше логики html никакой на back-end нету.
шаблоны еще клиентские бывают )
Ага. И вот тут к нам приходят уже заранее подключенные на статическую страницу js компоненты или другие штуки которые вам нравятся.
Они то всю динамику и логику интерфейса и делают.
То есть можно сделать компонент, шаблонизатор для него и в перед. И страница будет вообще работать как отдельное приложение. Каждая страница сервиса!
Они то всю динамику и логику интерфейса и делают.
То есть можно сделать компонент, шаблонизатор для него и в перед. И страница будет вообще работать как отдельное приложение. Каждая страница сервиса!
«Если появятся для этого API клиенты на iOS или Android, то им тоже надо знать где лежат шаблоны books-index?» — нет, суть в том что само веб приложение есть API.
Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.
На эту же страницу ставятся js компоненты или другие штуки, они то всю динамику и логику интерфейса и делают.
А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)
Вот и все.
Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.
На эту же страницу ставятся js компоненты или другие штуки, они то всю динамику и логику интерфейса и делают.
А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)
Вот и все.
Суть как раз в том, что API не должно быть веб-приложением. Оно само по себе, это просто интерфейс для доступа к данным.
«Проще говоря, почему мы не можем html через API слать, но html этот не содержит логики, это просто кусок html — меню, header, footer и прочие вещи которые не меняются.»
Можете, но это уже не API. Вы просто выдаете клиентские шаблоны для страниц.
«А для мобильников все так же, просто они не используют запросы которые возвращают html статику :-)»
Вы просто смешали чати приложения и API вместе, а потом говорите программисту «используй только эту часть, это true-API, а это чать веб-приложения». А потом вам понадобится дать доступ к API другим программистам, чтобы они на его основе сделали свое мобильное приложение и вы им выдадите вот это все. Они, конечно же, зададут вам вопросы «нафига нам html странички?», на что вы им скажете что это торчат части другого клиента и им их использовать не надо.
Пройдет время, вы захотите поменять свои веб-странички выдаваемые API и… в этот момент в комнату влетает разгневанный начальник/клиент/заказчик и кричит «верни все назад, у команды из Индии/Китая/Другой страны все рухнуло, это ты виноват!». И знаете, он будет прав, потому что кто-то из той команды программистов заиспользовал ваши html-шаблоны и теперь вы с ними связаны и не можете обновить ваш сайт.
А еще спустя какое-то время, вас попросят выкатить новую версию API, с немного другими шаблонами. И, вуа-ля, у вас уже три версии html-страничек: для старого API, нового API и вашего нового сайта.
«Проще говоря, почему мы не можем 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» — эти страницы часть веб клиента, в чем проблема если они поменяются?)
Но Бог с ним. Допустим мы вынесем из API html страницы.
Самое главное что веб приложение будет так же работать через REST API.
«А зачем мобильникам эти страницы ?) „
Да мало ли что взбредет в голову программистам, которым вы дадите это API. Может захотят сделать какие-то страницы внутри приложения на html.
Если в страницах (а это воспринимается как часть API) что-то изменится, то формально поменяется API.
“Самое главное что веб приложение будет так же работать через REST API.»
Вот об этом вам и говорят, что у вас просто веб-приложение работает через REST API, это не новый подход. Он давно практикуется в случаях, когда нужно чтобы на выходе и API было и приложение. И чтобы не писать для приложения отдельный back-end, его просто заменяют на API. А дальше, как правило, MVC-фреймворк на клиенте.
Сама разработка в таком случае строится на том, что параллельно с клиентской частью на html пишется API, которое просто выдает данные ничего не зная о специфике клиента. На стороне браузера, как правило, SPA, который просто с сервера подтягивает статичные шаблоны страниц и манипулирует ими. Вообще как устроен клиент, в данном случае не столь важно, т.к. к REST API можно прикрутить что угодно. Важно лишь то, что клиент отдельно, API отдельно.
Да мало ли что взбредет в голову программистам, которым вы дадите это API. Может захотят сделать какие-то страницы внутри приложения на html.
Если в страницах (а это воспринимается как часть API) что-то изменится, то формально поменяется API.
“Самое главное что веб приложение будет так же работать через REST API.»
Вот об этом вам и говорят, что у вас просто веб-приложение работает через REST API, это не новый подход. Он давно практикуется в случаях, когда нужно чтобы на выходе и API было и приложение. И чтобы не писать для приложения отдельный back-end, его просто заменяют на API. А дальше, как правило, MVC-фреймворк на клиенте.
Сама разработка в таком случае строится на том, что параллельно с клиентской частью на html пишется API, которое просто выдает данные ничего не зная о специфике клиента. На стороне браузера, как правило, SPA, который просто с сервера подтягивает статичные шаблоны страниц и манипулирует ими. Вообще как устроен клиент, в данном случае не столь важно, т.к. к REST API можно прикрутить что угодно. Важно лишь то, что клиент отдельно, API отдельно.
Для мобильников все по старому.
Это штука только для веб интерфейса.
Это штука только для веб интерфейса.
Есть же изоморфные/универстальные СПА, где один и тот же код рендерится и на сервере на клиенте, так что все ваши пункты теряют актуальность при таком подходе
А затем вдруг часть состояния с одной страницы нужно передать на другую и начинается гемор с сохранением его куда-то и дальнейшим восстановлением. Через какое-то время приложение становиться достаточно сложным и гемор с постоянным сохранением/восстановлением начинает перекрывать все другие плюсы. Выкидываем всё сделанное, пишем нормальное SPA.
SPA SPA рознь :)
Можно примеры SPA сайтов? :)
Можно примеры SPA сайтов? :)
Sign up to leave a comment.
SPA — не серебряная пуля, или альтернативный подход к web-разработке. Часть 1