и соответственно вставляли внутрь функцию его проверки

в web есть @after, но в rest вроде нет

кто-нибудь выходил из этой ситуации красиво?

"потому как в случае этой функйции вполне себе годный rest получается, на мой взгляд)" "но stateless он не гарантирует)" Во! Как я понимаю это ключевое! так?

Я просто пытаюсь понять где лучше одно, а где другое. Как я понимаю через rest лучше отдавать контент по токенам и все то что имеет JSON оcнову. Для всего остального лучше именно классический способ. Т.е. если у меня /users/user должны быть доступны только авторизованным пользователям, то я это как Rest делаю. При этом на клиенте должен быть уже подгружен шаблон рендинга. Если на клиенте ничего нет, то я генерю все на сервере без Rest и отдаю это в виде готовой HTML страницы так?

нет

для начала, rest принципиально не привязан к json

просто в vibe так сделанно

основное примнение - это общение между сервисами

Немножко наоффтоплю: Тут кто-то упоминал что писал на OCaml. Правильно я понимаю, что в нём мы по-сути никак не храним значения каких-либо вычислений? То есть, условно говоря есть тяжелое выражение А и каждый раз, как нам понадобится его результат оно непременно будет выплнено заново? Мне как-бы понятно чем это полезно, но для производительности это же смерть. Нет? Можно ли сделать хотябы локальную переменную, чтобы в пределах одной функции (тут ошибок связанных с состоянием быть не должно) можно было обойтись без повторных вычислений того, что можно посчитать лишь раз. Меня это интересует с тем, чтобы понять применим ли он (и вообще функциональщина) для меня или мне надо окончательно сломать мозг и найти способ как-то обойтись без повторных вычислений без использования переменных (со значением, а не выражением), что кмк далеко не всегда возможно.

там, где запрос делает сервис, и ответ анализирует он же - лучше всего применять rest

там где ответ получает человек - там rest не нужен

за OCaml не скажу, но обычно в функциональщине либо не надо вычислять что-то сложное дважды, так как структура кода к этому не располагает, либо вступает в игру кэширование. Чистота функций гарантирует возможность кешировать результат, так как он зависит только аргументов. Как с этим в OCaml не знаю

"там, где запрос делает сервис, и ответ анализирует он же - лучше всего применять rest" Просто вот допустим список пользователей которые есть в БД. есть смысл в виде rest делать?

ведь на клиенте тоже будет какая-то логика парсинга и отображения т.е. обработки

если этот список должен получить какой-то другой сервис, то да

Но отчасти же можно сказать, что на клиенте тоже какая-то логика есть обработки данных. Просто вот допуситим куча плагинов для js-фреймворков json ожидают. Тоесть получается тут rest все же нужен?

в таком случае rest оправдан

если речь о плагинах, то возможно, даже и нужен)

нужно понимать, что rest - это не протокол

это ближе к паттерну

за OCaml не скажу, но обычно в функциональщине либо не надо вычислять что-то сложное дважды, так как структура кода к этому не располагает, либо вступает в игру кэширование. Чистота функций гарантирует возможность кешировать результат, так как он зависит только аргументов. Как с этим в OCaml не знаю

Ну условно говоря (a + b) * c - (a + b) уже требует выполнить a + b дважды. Сделать ab = a + b соответственно не помогает. Понятное дело меня это не в арифметике интересует. Собственно для своего рода кеширования локальные переменные и нужны. Или этим должен компилятор заниматься? В таком случае понятно. Просто непривычно очень.

Да, компилятор "может" этим заниматься. В хаскеле есть https://wiki.haskell.org/Memoization очень-очень иногда компилятор это сделает сам, но в общем случае нет.

ну и по слову Memoization отлично гуглится для окамла

Sergey А для всего остального тогда генерация Урлов руками? Чтобы они там красивые были и все дела?

мемизация?

Немножко наоффтоплю: Тут кто-то упоминал что писал на OCaml. Правильно я понимаю, что в нём мы по-сути никак не храним значения каких-либо вычислений? То есть, условно говоря есть тяжелое выражение А и каждый раз, как нам понадобится его результат оно непременно будет выплнено заново? Мне как-бы понятно чем это полезно, но для производительности это же смерть. Нет? Можно ли сделать хотябы локальную переменную, чтобы в пределах одной функции (тут ошибок связанных с состоянием быть не должно) можно было обойтись без повторных вычислений того, что можно посчитать лишь раз. Меня это интересует с тем, чтобы понять применим ли он (и вообще функциональщина) для меня или мне надо окончательно сломать мозг и найти способ как-то обойтись без повторных вычислений без использования переменных (со значением, а не выражением), что кмк далеко не всегда возможно.

ОКамл не ленивый в отличие от Хаскелля, так что локальные переменные работают как обычно (и не локальные тоже). Можно даже изменяемые (не константные) переменные создавать и кодить "как везде". Даже исключения бросать умеет

А можно ли сайт целиком на rest построить?

В чем минусы будут?

Ты имеешь в виду REST апи + фронтенд который к нему ходит ?

Grigirii Почитал про меморизацию, понравилось. Делал в js что-то подобное (свойственными js костылями). @PeyTy То есть всётаки можно помимо выражений хранить и значения? В таком случае можно надейться, что в тупик не зайду. Спасибо)

В чем минусы будут?

Минус только в том что это сильно сложнее поддерживать на фронтенде - нужны клиентские шаблонизаторы и вообще богатый JS инструментарий. А так одни плюсы.

Grigirii Почитал про меморизацию, понравилось. Делал в js что-то подобное (свойственными js костылями). @PeyTy То есть всётаки можно помимо выражений хранить и значения? В таком случае можно надейться, что в тупик не зайду. Спасибо)

Можно

Павел, да

угу, понял спасибо)

На правах рекламы скажу, что мне очень https://vuejs.org/ нравится

Так, а как лучше всего по Rest отдавать отренденный шаблон vibed?

Или даже по-другому спрошу

Вот я генерирую на сервере разные вьюшки для разных групп пользователей. Как их на клиент отдавать в зависимости от события или пользовательской роли

А никак :) Клиент должен сам заправлять всеми вьюшками

бэкенд ему только отдает данные, сессию и т.д.

Все HTML/JS дела клиентское приложение делает само.

Это в идеале. А так то можно закостылить чтобы бэкенд отдавал куски html внутри json. Но от этого теряется вся прелесть разделения на фронт и бек.

Все HTML/JS дела клиентское приложение делает само.

Этож уже WebApp получается

А мы про него и говорим

Просто Дмитрий спросил так убдто у него не webapp. Тогда нужно делать REST-запрос и получать по нему данные в JSON, а дальше рендерить шаблонизатором на стороне клиента

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

Кстати, не могли бы подсказать где посмотреть примеры JSON API? Просто мне вот не понятно. Ну ок. Зашел пользователь на сайт. Дернулся урл /auth что туда должно быть отправлено? Что возвращено? Как поля лучше вложить и тд {{"auth":"true"}, {"login":"dima"} ,{"data":"mydata"}} так чтоли?

Кстати, не могли бы подсказать где посмотреть примеры JSON API? Просто мне вот не понятно. Ну ок. Зашел пользователь на сайт. Дернулся урл /auth что туда должно быть отправлено? Что возвращено? Как поля лучше вложить и тд {{"auth":"true"}, {"login":"dima"} ,{"data":"mydata"}} так чтоли?

как минимум это не валидный json

щас погоди проверю его

либо [{"auth":"true"}, {"login":"dima"} ,{"data":"mydata"}] либо {"auth":"true", "login":"dima" ,"data":"mydata"}

ай да точно

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

Я не фронтендер, но так понимаю что это тоже решается средствами фреймворка. Вьюхи хранятся в виде статики или JS файлов на сервере, и клиент когда надо запроашивает какие-то из них.

Олег, я правильно понимаю что ВСЕ json данные должны иметь какой-то общий шаблон. Т.е. различаться могут только какие-то конкретные поля, так?

Олег, я правильно понимаю что ВСЕ json данные должны иметь какой-то общий шаблон. Т.е. различаться могут только какие-то конкретные поля, так?

Ищи фреймворк работающий поверх vibed, ато затрагиваешь велосипедство

не шаблон, а правила построения

http://json.org/json-ru.html достаточно подробно, что как можно делать

ок понял)

м... я погуглил. Есть информация, что каждый JSON должен содержать поля data errors meta но вот с авторизацией как? Вот самое первое обращение сайта к серверу. Оно каким должен быть?

Просто мне понятно есть ли какие-то общепринятые вещи или все реально лепят кто-как?

JSON должен содержать поля data errors meta — нет

Просто мне понятно есть ли какие-то общепринятые вещи или все реально лепят кто-как?

да

каждый фреймворк будет придерживаться своих правил

а в vibe нет таких правил...

там json для rest это просто отображение структуры

ERROR: S client not available

ок буду дальше гуглить. Мне б что-то умеренно сложное

Вопрос. А токен нужно в base64 перекодировать? Или в поле token будут поля: { id: name: ... } (я про JWT авторизацию думаю)

просто можно же по идее: token: "base64-строка...." которая будет перекодированный токен содержать

какой интересный коммит в dmd https://s3.amazonaws.com/awesomescreenshot/upload//405518/a7194d60-f357-4238-583c-0955f43549c1.png?AWSAccessKeyId=AKIAJSCJQ2NM3XLFPVKA&Expires=1478558059&Signature=sXxqQbG5M58TKxJKxXcSfkNdKso%3D

какой интересный коммит в dmd https://s3.amazonaws.com/awesomescreenshot/upload//405518/a7194d60-f357-4238-583c-0955f43549c1.png?AWSAccessKeyId=AKIAJSCJQ2NM3XLFPVKA&Expires=1478558059&Signature=sXxqQbG5M58TKxJKxXcSfkNdKso%3D

Ась?

создан симлинк (пока что пустой) на фронтенд компялятора. Судя из названия для демона автодополнения

типа хотят в дистриб включить его?

недеюсь, что отделят ddmd в либу

хотя видел, что у haxe компилятор может работать как дополнятор

создан симлинк (пока что пустой) на фронтенд компялятора. Судя из названия для демона автодополнения

Пустой симлинк? Кто-то не умеет в git сабмодули?

это не ко мне)

Не может же линк ниначто не указывать

хм

Ах, это симлинк на папку src

м... я погуглил. Есть информация, что каждый JSON должен содержать поля data errors meta но вот с авторизацией как? Вот самое первое обращение сайта к серверу. Оно каким должен быть?

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

Правда поля meta у нас не было, но каждый обработчик мог узнать, есть ли ошибки в ответе, посмотрев в errors

Я тоже так делаю)

Я повнимательнее прочитал и вот что увидел:

почему data и errors нельзя сочетать?

Как тогда проверять прилетевший документ? Искать там поле data. если поле data нет, то искать errors?

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

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

Итого if(response.errors) {console.log("Дальше не продолжаем. В документе ошибка")} как-то так?

да

А что за доку ты читаешь? Скинь ссылку?

http://jsonapi.org/format/1.1/

На стороне клиента я просто обращаюсь к data (в try catch) и если уж хватаю иcключение, то лезу в errors и там определяю какое именно исключение кинуть дальше.

И как вы это всё понимаете __traits(compiles, swap(T.init, T.init))

И как вы это всё понимаете __traits(compiles, swap(T.init, T.init))

всего лишь проверка можно ли звать swap c аргументом типа T. что тут сложного или непонятного?

разве что то, что в других языках это вообще никак не написать