LINUX.ORG.RU

Кто-нибудь пробовал комбинировать REST API и стандартные HTML формы?

 , ,


0

1

Большинство проектов разрабатывается так. Есть некая HTML форма на (GET) example.com/signup, некая обработка запросов на (POST) example.com/signup (с возможным редиректом на GET). И отдельный REST API: example.com/api/signup, возвращающий (а иногда и принимающий) JSON.

Почему бы не объединить обе части, возвращая данные в заголовках? Посылаете вы «username», «fullname», «email», «password» на example.com/signup, а оно рендерит не просто ответ сервера в виде HTML (для браузера), но и дублирует необходимые данные в виде заголовков (для JS и мобильного приложения):

-------- start of headers
...
status: error
errors.fullname.text: Fullname cannot be empty.
-------- end of headers
...
<strong>Fullname cannot be empty.</strong>
<input name="fullname" type="text" class="error" value="">
...

Таким образом, нет необходимости отдельно продумывать и пилить API. Умный фреймворк (на самом деле даже простая библиотека) сможет автоматизировать всё это так, что всё будет происходить под капотом.

Какие тут подводные камни?

Какие тут подводные камни?

Гонять лишний раз HTML по сети, там где достаточно мелкого json-а? Да и вообще — нафига?

MrClon ★★★★★
()
Ответ на: комментарий от anonymous00

Это предложение, по нашим временам, уже тянет на экстремизм. Следи за собой, будь осторожен.
Но тут-то речь о том что нам уже нужно API (не важно зачем), и вот нафига смешивать его с обычным HTML как-то не очень ясно

MrClon ★★★★★
()

Клиент посылает правильный заголовок Accept на API

В зависимости от этого заголовка возвращается HTML или JSON (или 4орт лысый)

Зачем городить огород?

anonymous
()
Ответ на: комментарий от anonymous00

Не нагружать браузер юзера джаваскриптом вместо простой загрузки страницы?

Почему считается, что javascript нагружает браузер больше рендеринга HTML? Там вообще доли какие-то.

i-rinat ★★★★★
()

Посылаете вы «username», «fullname», «email», «password» на example.com/signup, а оно рендерит не просто ответ сервера в виде HTML (для браузера), но и дублирует необходимые данные в виде заголовков (для JS и мобильного приложения)

И чего вы этим добьетесь? Секономите один адрес?

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Почему считается, что javascript нагружает браузер

Потому что вебмакаки любят бесконечный цикл с отъеданием памяти... Потому что скрипт по загрузке контента в страницу не загрузит и не покажет, пока скрипт счётчика яндекса не раздуплится. Потому что сначала надо загрузить jquery с CDN. Который сегодня попал в блокировку. Потому что... В современном мире для субъективной скорости почему-то лучше один простой GET, и даже превьюшки интегрировать в BASE64. Но это изврат :(

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)

У меня сейчас в SPA шаблоны генерируются на стороне сервера. SPA на angularjs. Соответственно, при открытии чего-либо на редактирование, шаблон отдаётся с ng-init уже установленным.

Shadow ★★★★★
()
Ответ на: комментарий от i-rinat

А ты посмотри, как начнет тупить огнелис, когда откроешь жирный интерфейс гуглопочты!

Очень даже жабоскрипт грузит браузер. Жабоскрипта вообще минимум должен быть! В идеале, когда страница вся — гольная статика, жабоскрипта там вообще не нужно (все через html+css можно сделать).

anonymous
()
Ответ на: комментарий от anonymous

А ты посмотри, как начнет тупить огнелис, когда откроешь жирный интерфейс гуглопочты!

https://arewefastyet.com/

Вообще-то движок Javascript у Firefox достаточно быстрый. В некоторых тестах он даже опережает движок Chrome. А вот с рисованием HTML/CSS у Firefox беда, особенно под линуксами. Так что не всё так просто.

У гуглопочты, кстати, есть старый интерфейс. Он заметно легче.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)

мой CTO наркоманит щас систему (не SPA) на reactjs. зачем насиловать браузер генерацией html-говна в скриптах, если можно сгенерить выхлоп на сервере и отдать клиенту. жабоскрипт же уебище лесное.

anonymous
()
Ответ на: комментарий от anonymous

+1. В большинстве случаев, это будет самое адекватное решение. А то по навешают костылей на js, а потом решают вытекающие из этого проблемы.

th3m3 ★★★★★
()
Ответ на: комментарий от th3m3

Откройте шаблонизаторы http://mustache.github.io/ с json. Да, рендерится на стороне клиента, но не намного по нагрузке отличается от чистого html

Такой вариант для медленного соединения самое то, для того и api мутится, чтоб рендерить разными способами

ism ★★★
()
Последнее исправление: ism (всего исправлений: 1)
Ответ на: комментарий от anonymous

зачем насиловать браузер генерацией html-говна в скриптах, если можно сгенерить выхлоп на сервере и отдать клиенту. жабоскрипт же уебище лесное.

Зачем насиловать сервер и сеть, если можно можно сгенерировать все на клиенте?

anonymous
()
Ответ на: комментарий от anonymous

Зачем насиловать комп, если можно распечатать бланк на Почте России, заполнить его ручкой и отправить результат заказным письмом?

Bahamut
()
Ответ на: комментарий от Bahamut

Зачем насиловать браузер, если все можно на флеше сделать?

Shadow ★★★★★
()
Ответ на: комментарий от goingUp
  • Сокращение API surface.
  • Авто-документирование API. Форма уже user-friendly и предельно понятно, что она делает и какой формат данных ожидает.
  • 0 усилий со стороны разработчика. Во фреймворке есть структура данных «Flash», который уже содержит все необходимые данные, нужные клиенту. Остаётся засунуть его в заголовок, а не только в HTML.
anonymous
()
Ответ на: комментарий от MrClon

Гонять лишний раз HTML по сети

Не знаю, умеет ли такое JS. Но все другие ЯП сначала получают и парсят заголовки, а потом опционально переходят к телу страницы.

anonymous
()

Почитай про CSRF, Cookies, Sessions. API по определению stateless, ты же хочешь всё это смешать.

Deleted
()
Ответ на: комментарий от Deleted

Что конкретно почитать? Отправляешь нужную cookie - получаешь состояние, не отправляешь - не получаешь. Чем это по твоему не stateless? Или для stateless необходимо непременно переизобрести cookie на чистом JS и называть это jwt?

anonymous
()
Ответ на: комментарий от anonymous

Почитать что это и зачем используется.

Отправляешь нужную cookie - получаешь состояние, не отправляешь - не получаешь. Чем это по твоему не stateless?

Наркоман или просто джун? Тем, что каким-то криворуком будет предусмотрена возможность использовать апи с аутентификацией куками, а сама возможность этого — это уже не stateless.

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

Для работы с юзером на сайте — обработка данных форм, CSRF, куки, для клиентов апи — stateless с отправкой токенов. Вопрос в разделении сущностей по юзкейсам.

Если хочешь, чтобы веб был на апи без кук и так далее, так делай так сразу, а не изобретай монстра, который может всё в одном месте.

Deleted
()
Ответ на: комментарий от anonymous

Так остальное-то всё-равно будет отправлено скорее всего. Максимум — клиент сможет разорвать сетевое соединение где-то после того как получит заголовки. Но на практике я-бы на это не рассчитывал

MrClon ★★★★★
()
Ответ на: комментарий от Deleted

использовать апи с аутентификацией куками, а сама возможность этого — это уже не stateless.

Ты хипстерского kool-aid'а пережрал. Чем по твоему передача некого ключа в заголовке (cookies) отличается от его же перадачи в качестве параметра (jwt)? Кроме того, что cookies уже реализованы в браузере, а для jwt надо хипстобиблиотеку подключать?

возможность версионности апи

Единственный разумный аргумент.

Для работы с юзером на сайте — ..., для клиентов апи — .... Вопрос в разделении сущностей по юзкейсам.

Это как раз и ненормально. На кой плодить сущности вместо одного универсального решения? Либо API, либо HTML forms. Для первого нормальные ЯП в браузеры ещё не завезли. Остаётся второе.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.