SP
Vladimir Razuvaev
Это если один сервер и один клиент (web). Грабли с code-on-demand начинаются, когда у вас много клиентов %)
ну и еще - у тебя должен быть очень умный клиент. Фактически - браузер + пользователь. Это никому сейчас не нужно
Size: a a a
2018 January 22
VR
Ага, для "полноценного" реста нужен в первую очередь полноценный клиент
SP
ничего не поменялось
ты мог и раньше делать запросы вида:
/api?fields={foo,bar{baz}}I
я сужу с практической точки зрения
SP
просто с graphql это в разы удобнее
VR
С практической точки зрения graphql заменил те json api, которые все именовали rest'ом. А у нас тут просто терминологический мини-холивар, правда похоже об обном и том же говорим %)
SP
фактически идея как бы не новая, просто получила качественное исполнение и отказ от устоявшихся догм в духе "у каждого ресурса должен быть URI"
SP
всеравно все делают все через жопу, а так хоть меньше кастылей будет
SP
а вот то как сделаны мутаторы в graphql лично мне не очень нравится...
SP
хотя все лучше чем ничего)
VR
В том и проблема, что REST как концепция и был академической утопией, а все делают так, как им нежно
SP
Vladimir Razuvaev
В том и проблема, что REST как концепция и был академической утопией, а все делают так, как им нежно
небыл он утопией, это диссертация которая описывала идею, "почему мы сделали web именно так"
VR
филдинг не делал веб
SP
Vladimir Razuvaev
филдинг не делал веб
он делал диссертацию)
VR
сначала его сделали на практике другие, а он попытался описать что они сделали академическим языком
SP
обоснование для выбора подходов использующихся в семействе стандартов про http 1.1
SP
Vladimir Razuvaev
сначала его сделали на практике другие, а он попытался описать что они сделали академическим языком
и получить PhD
VR
это описание того, что было постфактум %) Но почему-то решили, что это академическое описание подойдет для любых веб-API
SP
он как бы учавствовал в формировании спецификаций) так что он в каком-то смысле делал web)