мне нравится больше пример про "миллиционеры как подтип людей".

Разве те из них, что оборотни, - могут быть подтипом людей?

Разве те из них, что оборотни, - могут быть подтипом людей?

Собака может быть милиционером, плохой пример

Собака может быть милиционером, плохой пример

Так а что от чего наследовать?)

di

тонко

Вопросы по пхп в чатик по пхп

Вопросы по пхп в чатик по пхп

ок хотя не совсем по теме php это скорее по структуре кода

ок хотя не совсем по теме php это скорее по структуре кода

Структура кода от языка всё же зависит, так как исключительно пхп-шные конструкции используются.

а по проектированию есть какие-нить чаты? а то, боюсь, у нас опять свои велосипеды начнут писать, интересует конкретно rest api, лично у меня в голове каша, че-то про микросервисы слышал, но не понимаю какое они к этому апи отношение имеют (если имеют)

а по проектированию есть какие-нить чаты? а то, боюсь, у нас опять свои велосипеды начнут писать, интересует конкретно rest api, лично у меня в голове каша, че-то про микросервисы слышал, но не понимаю какое они к этому апи отношение имеют (если имеют)

А что тебе от реста надо?

Ты всё равно с первого раза нормально не спроектируешь.

мне ничего ) у нас хотят писать его, есть кодовая база на первом зенде, там есть какая-то реализация апи (не рест), хотят на yii апи запилить, просто пока есть возможность - можно посоветовать что и как делать (пока спрашивают, потом поздно будет))

мне ничего ) у нас хотят писать его, есть кодовая база на первом зенде, там есть какая-то реализация апи (не рест), хотят на yii апи запилить, просто пока есть возможность - можно посоветовать что и как делать (пока спрашивают, потом поздно будет))

могу только порекомендовать найти уже готовую хорошую реализацию И изучить ее

А разве в YII нет уже готового REST ?

Тема-то попса

а по проектированию есть какие-нить чаты? а то, боюсь, у нас опять свои велосипеды начнут писать, интересует конкретно rest api, лично у меня в голове каша, че-то про микросервисы слышал, но не понимаю какое они к этому апи отношение имеют (если имеют)

можно просто спросить @fes0r и он объяснит, почему rest api это такой "миф"

по мне в плане реализации graphql лучше выглядит

для бэка - да, с клиентами не все так просто

для бэка - да, с клиентами не все так просто

а разве для бека да?

да, куча либок, куча крутых штук

лимиты, авторизация, ошибки

там ж как куча крутых штук, так куча супер банальных нерешенных проблем

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

Вопрос а есть инструменты которые чертят UML структуру Из уже существующего кода ?

Есть проект надо классы отобразить

вроде idea умеет

https://mamuz.github.io/PhpDependencyAnalysis/

спс!

лимиты, авторизация, ошибки

ошибки к слову решает. С лимитами добавляет своих проблем (надо вводить анализ стоимости запросов для филдов например)

но все сводится к тому что идея использовать http как application level протокол так себе

полюбому придется расширять своими велосипедами

есть еще odata для вдохновения

А разве в YII нет уже готового REST ?

как по мне, это равносильно "чтобы было ооп - пиши на классах", вроде верно, но ни фига не объясняет )) та же MVC - ну есть она в зенде, а я так код напишу, что от нее толку никакого не будет. Меня не столько даже рест, сколько вообще написание апи интересует, хотя бы что-то типа "паттернов для апи", т.к. сомневаюсь, что для нормального апи (в том числе для масштабируемости) достаточно будет просто методы наружу бросить и через тот же swagger сделать документацию. Иначе можно взять soap, нагородить там фигню всякую, а потом гордиться своим "апи". Да, все круто будет, клиенты легко им пользуются, но внутри ад кромешный будет. Взять те же микросервисы - сомневаюсь, что у меня с первого раза без предварительной подготовки получится написать нормальную реализацию. Так же и с апи, тем более там новичку (относительно новичку, не знаю его уровень) писать поручили, а потом переделывать вряд ли станут

> ну есть она в зенде нету

> паттернов для апи 1. token-based аутентификация, self-contained токены, JWT 2. делать все респонсы объектом. Ну мол коллекция будет выглядеть как {data:[{item}]} 3. пагинация курсором, удобная и гибкая штука. Еще можно покурить про continuation tokens, их фэйсбук юзает 4. инклуды, возможность компонавать ресурсы из ресурсов (тут graphql тип самое крутое что есть)

так. ладно. не оффтопим

как по мне, это равносильно "чтобы было ооп - пиши на классах", вроде верно, но ни фига не объясняет )) та же MVC - ну есть она в зенде, а я так код напишу, что от нее толку никакого не будет. Меня не столько даже рест, сколько вообще написание апи интересует, хотя бы что-то типа "паттернов для апи", т.к. сомневаюсь, что для нормального апи (в том числе для масштабируемости) достаточно будет просто методы наружу бросить и через тот же swagger сделать документацию. Иначе можно взять soap, нагородить там фигню всякую, а потом гордиться своим "апи". Да, все круто будет, клиенты легко им пользуются, но внутри ад кромешный будет. Взять те же микросервисы - сомневаюсь, что у меня с первого раза без предварительной подготовки получится написать нормальную реализацию. Так же и с апи, тем более там новичку (относительно новичку, не знаю его уровень) писать поручили, а потом переделывать вряд ли станут

НЕ ДЕЛАЙ МИКРОСЕРВИСЫ

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

ну мол если не умеешь монолиты готовить микросервисы точно не выйдет

просто в монолитах у тебя будут ивенты на уровне процесса одной машины, а в микросервисах - какой-нибудь RPC на json между разными машинами

> паттернов для апи 1. token-based аутентификация, self-contained токены, JWT 2. делать все респонсы объектом. Ну мол коллекция будет выглядеть как {data:[{item}]} 3. пагинация курсором, удобная и гибкая штука. Еще можно покурить про continuation tokens, их фэйсбук юзает 4. инклуды, возможность компонавать ресурсы из ресурсов (тут graphql тип самое крутое что есть)

+

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

хотя jwt штука прикольная но я ее боюсь

хотя jwt штука прикольная но я ее боюсь

нужно просто скипать alg в хидерах) и тогда не страшно

ну и HS256 по дефолту вместо RSA

ну у нас тоже jwt

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

главно что бы alg: none нельзя было сделать короч

а так чего боишься?

удобная ж штука

то что для мгновенной инвалидации надо блэклисты делать? или что?

у нас алгоритм защит внутри

для сеюрности

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

ну и еще надо смотреть что в пэйлоад кладут

а то как-то застал одного который положил email пользователя в jwt

ERROR: S client not available

вот я этого и боюсь

у нас сессия в jwt целиком)

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

ну мы тоже)

но найдется мудак что в сессию сложит что то большое

чего бояться то?)

и кука разбухнет и браузер не скушает)

а ну как... тоесть у тебя нет рефреш токенов?

но найдется мудак что в сессию сложит что то большое

ну тут такое, у меня там ровно то что надо для аутентификации. айдишка юзера, что он могет или чего он не могет, никнейм и аватарка)

не я его вводил)

не читал еще подробно просто сама идея хранения данных в пользователе интересна

у нас айдишка в основном

рефреш токены в целом это защита от MitM атак, оно только для этого надо

а для инвалидации надо мутить блэклисты. у меня их нет и я грущу)

или не делать jwt)

или не делать jwt)

тогда я буду грустить еще болше

это ж так круто

тебе приходит http запрос и там все что надо для его обработки

но только нужны блек-листы = не все)

а так решается фронтовой мидлварой, которая этим займется

ну как бы да)

а jwt позволяет твоей мидлваре не ходить никуда

у нее все есть

кроме блеклиста?)

ну блэклист у нее ж будет)

рэдис какой

ну так я могу и сессии ей отдать