причём тут гипертекст...

элементы гипермедиа, та штука которая является краиугольным камнем такой характеристики архитектурног остиля rest как unified interface

формы, ссылки...

то что позволяет масшабировать web до бесконечности

для мобилки тебе такое не надо

ты там все урлы хардкодишь. А если не урлы - то детали схемы.

элементы гипермедиа, та штука которая является краиугольным камнем такой характеристики архитектурног остиля rest как unified interface

а каким образом интерфейс относится как дизайну апи ?

в википедии не нашел ничего на этот счет

ну филдинга почитай/посмотри. В википедии к слову есть отсылка на изначальную идею за этой диссертацией Филдинга с которой все носятся - его попросили обосновать архитектуру вэба времен http 1.1

https://twitter.com/fielding/status/324448353180061696?lang=en

особенно забавляют люди которые говорят про некую мифическую "спеку rest"

люди даже по http спеки не читают

а rest он как бы.... representational state transfer, то есть о переходах стэйта

и переход стэйта этот происходит за счет элементов гипермедиа

Рой Филдинг - автор диссертации о "Архитектурные стили бла бла", тот человек который ввел термин REST

объективнее некуда

вот когда ты мне объяснишь почему REST называется REST

тогда поговорим)

ну смотри

в оригинальном вопросе используется термин REST API

не RESTful programming в целом

не RESTful programming в целом

этот термин ты откуда родил? дай определение)))

в оригинальном вопросе используется термин REST API

на что я ему сказал что "REST API" не бывает. И не стоит загонять себя в рамки REST

и далее по пунктам дал ответ

а про "rest api не бывает" - это уже с тобой разговор

так что не передергивай

не бывает rest api только если быть petty

ясно понятно

Признаться, я всё ещё не в полной мере улавливаю, почему не может быть state transfer в приложении к API.

Признаться, я всё ещё не в полной мере улавливаю, почему не может быть state transfer в приложении к API.

сча картинку найду

Признаться, я всё ещё не в полной мере улавливаю, почему не может быть state transfer в приложении к API.

ты под state transfer подразумеваешь видимо хождение json-ок между клиентом и сервером, так?

Вообще говоря нет.

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

конкретно - зачем тебе unified interface и в чем он у тебя будет выражаться?

или тебе хватит rpc поверх http?

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

В целом я заинтересован малыми усилиями масштабировать отдельные части системы вслед за потребностями бизнеса.

В целом я заинтересован малыми усилиями масштабировать отдельные части системы вслед за потребностями бизнеса.

это то зачем ты микросервисы взял (и скорее всего рассматриваешь cqrs+es)

тебе надо организовать общение микросервисов

это просто обмен сообщениями. Кто-то делает шину сообщений на кроликах например

кто-то юзает http

кто-то grpc

это все детали

они не важны, важен сам факт общения

и как бы... если возвращаться к вопросам SOLID - там так же важны не сами объекты а их взаимодействие

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

information hiding и все такое

Именно так

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

в случае сложных действий у тебя всеравно будут штуки вроде POST/PUT /users/{id}/approve

или что бы меньше походило на rpc

POST /users/{id}/userApprovedEvent

или команда

поскольку на микросервисы так же распространяются SRP и т.д. у тебя там не будет больших апишек

поскольку на микросервисы так же распространяются SRP и т.д. у тебя там не будет больших апишек

Ага

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

Да, пока подход вроде как полностью ясен. Собственно это "вокруг меня" и происходит сейчас.

Вероятно мне стоит прочесть Роя Филдинга - есть шансы, что мы понимаем разные вещи под REST.

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

Вероятно мне стоит прочесть Роя Филдинга - есть шансы, что мы понимаем разные вещи под REST.

хз я забил

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

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

это единственное полезное что я усвоил потратил пол года на изучение всей этой фигни про rest

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

но диссертацию почитать стоит, там есть полезные штуки

да и она не большая

В целом я раз за разом встречаю ситуацию, когда на двух человек - три разных мнения "что такое REST". (все три, конечно, верные)

В целом я раз за разом встречаю ситуацию, когда на двух человек - три разных мнения "что такое REST". (все три, конечно, верные)

"что такое ООП", "что такое MVC"

вот еще прикольные аабривиатурки на которых можно такой эффект словить

:)

лол

Вопрос по архитектуре.

Вот есть, например, сущность Resume (резюме) и доменное событие ResumeCreated.

Можно ли считать адекватным решение записывать данные в БД по возникновению этого события?

Будем считать, что полноценного ORM типа Doctrine нету.

Можно ли считать адекватным решение записывать данные в БД по возникновению этого события?

тогда лучше в базу и само событие записывать

Для чего?

что бы можно было восстановить состояние

Как называются объекты-хранилища без логики, которым не доверяют? DTO? Хочу пропускать их через валидатор, а сущности держать всегда валидными. В сети пишут, что DTO изначально были придуманы, чтобы уменьшить количество запросов (HTTP?) между системами, не совсем то.

Dto подходит

DTO - это такие классы хранилища, которые делаются для перемещения данных между слоями. В твоем случае видимо между HTTP слоем и доменом... А вообще - так ли важно как называются такие классы? :)

DTO - это такие классы хранилища, которые делаются для перемещения данных между слоями. В твоем случае видимо между HTTP слоем и доменом... А вообще - так ли важно как называются такие классы? :)

DTO это объекты, а не классы )

не придирайся

Спасибо за ответы. Здесь именование важно, так как имена DTO часто дублируют имена сущностей, нужно как-то отличать.

UserDTO?

или не айс?