Еще любимое про rest https://mobile.twitter.com/fielding/status/324448353180061696

ну то есть я могу понять если "фасадом" там называют то что возвращает Database:: штука (или че там есть хз не юзал), и это именно фасад наз базой. Но люди сам доступ фасадом называют

потому что глупенькие

"мы будем делать rest на mvc архитектуре что бы придти к микросервисам"

какой-нибудь такой булшит

Event sourcing на eloquent

Еще любимое про rest https://mobile.twitter.com/fielding/status/324448353180061696

я помогу людям - Рой это тот чел который ввел термин REST если непонятна шутка

"мы будем делать rest на mvc архитектуре что бы придти к микросервисам"

тема для конференции готова

тема для конференции готова

воркшоп на 8 часов, че

тут все считают что рест гавно?

а что такое рест?

тема для срача

тут все считают что рест гавно?

тут все считают, что рест апишек не существует)

(мои мечты)

graphql нас спасет?

ну graphql норм, но можно и просто json api делать

тут все считают что рест гавно?

Мне кажется rest по сути просто собрал в себя часть стандарта HTTP и пытается вывалиться как что то новое

хотя HTTP и сам не идеален

ну graphql норм, но можно и просто json api делать

А что ыт понимаешь под josn api? вроде если ты возвращаешь json то это уже jsonapi

http://jsonapi.org/

graphql нас спасет?

нельзя противопостовлять несуществующей вещи существующую

А что ыт понимаешь под josn api? вроде если ты возвращаешь json то это уже jsonapi

да я тоже об этом подумал

http://jsonapi.org/

ага, есть много вариантов

А что ыт понимаешь под josn api? вроде если ты возвращаешь json то это уже jsonapi

да, в целом любой json rpc over http норм, или xml или что хочешь

первый шаг - признать, что у тебя rpc

ну то есть....

первый шаг - признать, что у тебя rpc

а ну вот) то есть основа rpc

а протокол уже дело 10

а протокол уже дело 10

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

Все таки было бы не плохо следовать какой то проверенной методике формирование запросов/ответов. Что можете тогда порекомендовать?

да, именно так. А если еще непонимаешь почему REST API не существует - единственный реальный пример REST - это web. То есть вся совокупность, http, html и т.д. Гипертекст и code on demand. То есть у тебя есть браузер который ничегошеньки не знает о том что куда ты хочешь и что там есть.

Все таки было бы не плохо следовать какой то проверенной методике формирование запросов/ответов. Что можете тогда порекомендовать?

http

http

это транспорт для твоего приложения, все остальное ты наворачиваешь выше сам

Все таки было бы не плохо следовать какой то проверенной методике формирование запросов/ответов. Что можете тогда порекомендовать?

json api?

короч если ты хоть какие-то знания о сервере хардкодишь на клиенте - будь то урлы, структуры данных и т.д. - то это уже не REST. И не надо.

я видел много крайне паршивых json api

я видел много крайне паршивых json api

а я много крайне паршивых "хреней" которые люди называли REST-ом)))

Транспорт? Транспорт это жи TCP, с использованием хттп тебе уже надо будет соблюдать правила запроса ответа и разгулятся тебе не дадут...

а я много крайне паршивых "хреней" которые люди называли REST-ом)))

ну да нормальго REST я тоже не видел

ну да нормальго REST я тоже не видел

ну так о чем "проверенном" мы говорим)

Транспорт? Транспорт это жи TCP, с использованием хттп тебе уже надо будет соблюдать правила запроса ответа и разгулятся тебе не дадут...

мы тут про "транспорт" верхнего уровня над http )

Транспорт? Транспорт это жи TCP, с использованием хттп тебе уже надо будет соблюдать правила запроса ответа и разгулятся тебе не дадут...

Единственное приложение которое может использовать http как application level протокол - это браузер. Все. Дальше все всеравно наворачивают что-то сверху. Взгляни хотя бы на WebDAV

а так http хорошо подходит для RPC)

Транспорт? Транспорт это жи TCP, с использованием хттп тебе уже надо будет соблюдать правила запроса ответа и разгулятся тебе не дадут...

так для rpc over http хттп как раз транспорт)

в общем что есть транспорт зависит от того, с какого угла вы смотрите)

в общем что есть транспорт зависит от того, с какого угла вы смотрите)

ну так то можно для любого текущего уровня назвать транспортом предыдущий

ну так то можно для любого текущего уровня назвать транспортом предыдущий

У тебя есть приложение которое ходит на сервер по определенным урлам и постит определенные структуры. Это ли не протокол уровня приложения? И если так, использует ли приложение http тупо как транспорт?

то есть такие штуки как http cache framework - ты его юзаешь в контексте API? Или ты кэш обычно все же на уровне приложения реализуешь?

ну так то можно для любого текущего уровня назвать транспортом предыдущий

не уверен, что именно так, но вполне возможно

ну можно транспорт разделить допустим на два уровня) первый будет http - а второй это то протокол котоырй мы приняли в приложении - будет трансопртом для нашей логики

тут больше вопрсо в именовании и сопоставлении с OSI

ну можно транспорт разделить допустим на два уровня) первый будет http - а второй это то протокол котоырй мы приняли в приложении - будет трансопртом для нашей логики

"транспорт для логики" - очень мощная терминология, точная прям

тут больше вопрсо в именовании и сопоставлении с OSI

с точки зрения OSI все это application level

и нас не особо интересует OSI в этом контексте)

А как сделать версионирование в json rpc?

или этот вопрос вообще не должен возникать

Нид хелп ... захотел купить бумажное издание Фаулера, но есть "Шаблоны корпоративных приложений" и "Архитектура корпоративных программных приложений" ... судя по оглавлению одно и тоже и количество страниц тоже одинаковое. Но ISBN разный. Что лучше?

А как сделать версионирование в json rpc?

для простых случаев: /v1/ /v2/

в смысле?

и куда эти v1 v2 девать?

blabla/api/v1/blblbla

у меня ж вроде как единый эндпоинт, через который я коллбэки вызываю

мы точно про json rpc говорим?)

у меня ж вроде как единый эндпоинт, через который я коллбэки вызываю

ну вот единый, если он не предусматривал версионирование, редиректишь на условный v1 надо что-то сломать в обратной совместимости - делаешь v2 и ломаешь там.

ну а в чем проблема hostname/api/v1/endpoint ?

ERROR: S client not available

окей

а какие то best practices есть?

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

а какие то best practices есть?

я имею ввиду не с подменой версии в роуте

я имею ввиду не с подменой версии в роуте

передавать версию в джсон?

тоже об этом подумал

а на уровне класса как грамотно версионировать методы?)

в таком случае

через неймспейсы делать два разных класса?

а на уровне класса как грамотно версионировать методы?)

У нас было когда разные версии апи - это разные инстансы одного приложения

и в зависимости от роута заруливаешься на нужный инстанст

Удобнее когда версия указывается в схеме

Так как она всё равно меняется от версии к версии

для простых случаев: /v1/ /v2/

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

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

это годный вариант когда вся API меняется. Например у тебя есть API ты понял что все сделано через жопу и надо все прям переделывать

лучше через хедеры)

господа, куда бы вы запихнули некую сучность конвертации входящих данных аля старые-новые названия переменных в Request ?

мидлвары, пайплайны, адаптеры

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

мидлвары, пайплайны, адаптеры

делему нашел

тебе нужен какой-то способ задать мэппинг - а это уже надо исходя из ситуации смотреть как проще/лучше

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

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

мидлвары и так адаптеры

так что я не понимаю как тебе мидлвары не подходят а адаптеры уже подходят)

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

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

ну херня же

но как хочешь

я бы конвертил из старого в новый и уже новый валидировал бы

не могу, потому что ошибки валидации будут сыпаться не на price, а на globalUnitPrice переменную