да, почитай)

прям с болью написано

один - конкретный, второй - объединение 3-х

Спасибо

> RESTful: resources living each on its own URL, and manipulated exclusively through HTTP protocol. блин но это не REST... это HTTP

гипертекст же...

без него нет той самой инкапсуляции переходов которая собственно и делает REST ценным

HTTP 1.1 собственно ж потом уже был

> update (PUT/PATCH) PATCH не является частью HTTP. Да и в спеке HTTP не прописана семантика

вроде как... только должен метод быть идемпотентным или нет

короч у меня вопрос - где, где люди берут эти "истины"

на сайтиках типа resttutorial?

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

ну и смешание понятий "ресурс" и "модель данных"... ух

> When you ask how HATEOAS is supposed to work. доставило)

ну короч боль понятная....

написал там маленький ответик

ммм... ты читал письмо Роя? о курице и яйце? ;)

https://web.archive.org/web/20091111012314/http://tech.groups.yahoo.com/group/rest-discuss/message/6757

да, давненько было дело)

PATCH не является частью HTTP в смысле почему? есть же rfc на patch... или ты про то, что формат запроса не описан? ну к слову есть и на это rfc :)

PATCH не является частью HTTP в смысле почему? есть же rfc на patch... или ты про то, что формат запроса не описан? ну к слову есть и на это rfc :)

ну тип он не включен в спеку, это отдельная спецификация, как тот же WebDAV - он тоже нехило так http расширяет

хотя в целом пофиг да, но без спеки с примером что есть "description of changes" - толку то

а там полезут всякие RFC по json patch

и будет очень большой вопрос - а накой это все и чем это лучше старого доброго json rpc?

кто-то начнет везать за "REST не требует документации так как формат подразумевает self-discoveribility (или че там), но увы дока всеравно понадобится.

кто-то ее что-то невнетное будет бубнеть...

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

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

на самом деле спека по json patch которую я видел, там просто частично измененный документ, никакого доп синтаксиса... ща поищу

на самом деле спека по json patch которую я видел, там просто частично измененный документ, никакого доп синтаксиса... ща поищу

я понимаю, но ты пробовал подобное на клиенте имплементить?)

это ж своего рода UoW нужен (что в целом не сложно и я знаю наркоманов кто так делал)

мм... зачем uow?

https://tools.ietf.org/html/rfc7396 вот оно

Кто знает, каким образом симфони генерирует название файла для контейнера? var/cache/test/srcTestProjectContainer.php У меня вместо srcTestProjectContainer генерируется publicTestProjectContainer

https://tools.ietf.org/html/rfc7396 вот оно

да, я видел, но вот честно - я не представляю кому это может понадобиться в терминах API (только если им json patch не придется слать)

миниоффтопик есть кого почитать в медиуме? дошли руки поставить приложение на телефон

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

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

но почему ты думаешь что это мне, как клиенту, удобно?

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

вот я с позиции документации больше думаю...

а то будет у меня метод в духе update(ChangeEmailRequest | ChangePasswordRequest | ChangeEmailRequest req)

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

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

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

а вот если мне надо присылать скажем апдейты с клиента, которые аккамулируются в жирненький патч или коллекцию ивентов - что мне мешает POST заюзать? он по сути универсален

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

тебе никто не мешает так же делать и с patch и вообще с http api

тем более сейчас есть варианты описания схемы так, что бы небыло двусмысленности (с автоматической проверкой)

и генерацию доки можно запилить

но это http api будет а не rest api

бо нет гипертекста, только структуры данных

@fes0r Мне кажется граф скоро вытеснит рест, рест останется буквально в тех местах где пару адресов на гет, и 1 адрес на пост, и все

@fes0r Мне кажется граф скоро вытеснит рест, рест останется буквально в тех местах где пару адресов на гет, и 1 адрес на пост, и все

я больше вижу это как... толчек в развитии. graphql уже развивается слишком медленно как по мне

@fes0r а соап в отличии от реста и графа был слегка монстроузорен и крив в настройке, наверное по этому в свою очередь его и выдавил рест

@fes0r а соап в отличии от реста и графа был слегка монстроузорен и крив в настройке, наверное по этому в свою очередь его и выдавил рест

да, soap был хорош когда ты и клиент и сервер на дотнетах писал)

джависты завидовали и убили

ладно, это все не важно...

в любом случае graphql на php пока-что больно

ладно, это все не важно...

Ничего не важно в этом мире)

в любом случае graphql на php пока-что больно

Прям вот боль? Я вроде пару тестов гонял, и все достаточно неплохо и быстро в отличии от рест

ну терпимая боль

когда там @SerafimArts допилите свой SDL?

Прям вот боль? Я вроде пару тестов гонял, и все достаточно неплохо и быстро в отличии от рест

просто ты видел как на ноде с SDL для graphql апишки удобно писать?

в php это будет где-нибудь через пол годика

судя по всему. не раньше

я все хочу свою реализацию сделать но тааак лень

когда там @SerafimArts допилите свой SDL?

Вроде уже

с учетом того что ближайшие пол года мне не грозит переход на graphql

ERROR: S client not available

Вроде уже

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

@SerafimArts мы вызываем тебя

ась?

SDL уже можно брать и фигачить

все ж просили, я и зарелизил как мог

SDL уже можно брать и фигачить

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

доку потихоньку дописываю

сайт перефигачил чуток

ну не успеваю всё подряд и сразу =)))

Из приоритетных вещей: 1) Дописать доки по рефлексии, чтоб уже кто хотел мог SDL юзать с юшидо или вебониксом 2) Доделать билдер из оной в схемки вебоникса

Никита сейчас с yacc разбирается, хотим на него с Hoa перевести компилъ

@fes0r http://webonyx.github.io/graphql-php/type-system/type-language/ смотрел?

о, прикольно, запилили уже...

чортъ

меня обогнали :D

Я один про это знал? )

меня обогнали :D

Лох )

пару месяцев назад этого не было

пару месяцев назад этого не было

Это несколько недель назад запилили

ну вот раз зашел разговор

вот есть у нас филд возвращающий коллекцию

и у айтемов есть чайлд филд что бы чего сделать

будущее за бинарными протоколами типа gRPC, Thrift и Avro

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

будущее за бинарными протоколами типа gRPC, Thrift и Avro

это типа прошлое уже)

это типа прошлое уже)

как сказать

2013-ый какой-нибудь или 14-ый

да и потом, ты можешь спокойно юзать тот же срифт с graphql

в теории

gRPC в 2014м не было если чо

protocol buffers были, но немного в других местах

а сам grpc релизнулся только год назад с копейками