элементы гипермедиа. В контексте web - теги form и a (и link еще)

Это rest full же, просто для rest это не обязателтно же

а как же rest state less легкая масштабируемость, транспортный протокол http ?

вопервых про транспортный протокл REST ничего не говорит. Он про stateless (позволяет тебе горизонтально масштабировать ситему, ставить прокси/кешеры), про unified interface (hateoas часть этого), про то что client-server (где клиент это что-то что запрашивает а сервер это то что обрабатывает)...

Это rest full же, просто для rest это не обязателтно же

почитай Роя Филдинга

"просто rest" это и должно было быть "rest full" твое. Можешь называть "rest-like" например и мир будет в порядке

погоди

но по факту никому это не надо

soap

это rest только с Json вместо xml

если мы о hateos

нет, soap не умеет в hateoas

что за косяк? может можно его пофиксить без микросервисов?

Косяк - сам деплой, если косяк пофиксить, то микросервисы можно будет спокойно юзать, сейчас из-за деплоя не хотят их

это rest только с Json вместо xml

суть в том что json не гипертекстовый формат. А xml - гипертекстовый.

и сравнивать soap vs rest не корректно. Это сравнение конкретной технологии с архитектурным стилем.

так там всякие wsdl

так там всякие wsdl

это дока по API

не более

которые описывают как путешествовать по этому аду и тд)

вот так захочешь чатик почитать, а там ругаются

которые описывают как путешествовать по этому аду и тд)

для интерпритации доки всеравно человек нужен. А "не хардкодить урлы на клиенте" - это техническая задача.

ну тоесть вера в то что ты сделал все такое каноничное

rest

фэйлится

и у тебя буду клиенты которые без доки разберутся как с ним работать

и что они будут образованы и понимать все это

мало верояетно)

если у тебя где-то на клиенте захардкожены: - структуры данных - урлы - релейшены (если ты даже урлы не хардкодил) - http verbs какие делать то у тебя нет и не будет rest

фэйлится

ну или даже так

тут поправка

то что у тебя не RESTful API это как бы... нормально) ибо сама концепция RESTfull API бред

https://www.drupalwatchdog.com/sites/default/files/images/web/4.1-RESTfulness-tweet.png

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

они хотят что бы им приходило все в json

им от http статус кодов нужны только ошибки на уровне транспорта (400, 401, 403, 429, 500)

и изволь дублировать их в json

и концепция URI им как бы не ок... скажем в retrofit не так удобно урлы абсолютные пихать а code-on-demand на мобилках только в мечтах

ну так получается

и изволь дублировать их в json

А эт нафига?

апи вк, твиттера и тд типо rest

А эт нафига?

а им так проще

но нихуя не rest :D

и они не правы)

и они не правы)

просто слова REST потеряли смысл

а им так проще

у них есть готовые либы для этого

точно так же как ООП, soa, MVC, и начинают уже микросервисы (раз кто-то зовет свою систему с микросервисной архитектурой раз у него CRON джобы есть)

просто слова REST потеряли смысл

но ты же понимаешь это твой взгляди и взгляд еще какого то числа людей

и вас меньшинство

у них есть готовые либы для этого

С которыми они работать не хотят

а нормальность в мире это то как думает большинство

и вас меньшинство

потому мне в целом импонирует стратегия фэйсбука "переименовывать" вещи

так все в конечном итоге поступают

Да взять тоже bdd

есть доклад на тему "10 yers of BDD, all wrong"

Ну вот

Пора переименовать)

https://www.youtube.com/watch?v=2EM4itu7j7I

Я смотрел вроде

потому мне в целом импонирует стратегия фэйсбука "переименовывать" вещи

получается еще один синоним

и еще больше не разберихи)

и еще больше не разберихи)

посмотри видос Грэга на тему микросервисов (Олег выше кидал)

там он ретроспективку неплохую такую приводит

да лень что то )

от микросервисов (201x) до actor model и network (60-ые)

и синонимов там куча

ну я согласен с тем что все хипстерское

это просто кто то умную книгу читает

берет от туда идею

называет по своему

ERROR: S client not available

и получается что то новое

начинаешь копать находишь книги и тд что на него повлияло при разработке

и что все уже давно придуманно

ну я согласен с тем что все хипстерское

интересный факт... хипстры появились в 40-ых

хипстерство это мой термин ) на хайп

те кто бегают за хайпом

на практике никогда не работали с кодом который надо было бы поддерживать больше года

и меняют языки и технологии и подход

и что все уже давно придуманно

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

но как специалиста помимо моего уровня знаний

надо опираться на уровень знаний команды

и не все хорошо образованны

и кого то надо до обучать

команда тоже часть ситуации

надо опираться на уровень знаний команды

их можно научить

их можно научить

если это того стоит

я написал уже)

но например если команда дно нет смысла тащить что-то сложное

и если ты понимаешь что с текущей командой вы не справитесь.... ну тут хз что делать если честно

увольняться... или иже реквестить новых людей (а это процесс длительный)

хотя челендж неплохой

и если ты понимаешь что с текущей командой вы не справитесь.... ну тут хз что делать если честно

бля, ну тут хз как в такую ситуацию попасть

но каждый новый человек в команду

это замедление пока он не освоится

это замедление пока он не освоится

тут прямо как good design vs no design

no design вначале быстрее

ну на самом деле можно перестроить процесс, парное программирование там, код ревью регулярное

но опять же, это все индивидуально

ну на самом деле можно перестроить процесс, парное программирование там, код ревью регулярное

ой не факт не факт))

у нас вон code review

так таски огромные их реально ревьюить сложно

и там каша