VS
какой нибудь clientType в боди
Size: a a a
2021 November 17
СА
Доки Джавы - с болью и кровавыми слезами. Прочитал все описания конструкторов - пошёл попил чаю.
PD
Ну, вообще именно так.
У тебя же в любом случае разные entrypoint, что в RPC, что в REST.
Только в RPC ты их структурируешь по доменам, а не по сущностям, что логичнее.
У тебя же в любом случае разные entrypoint, что в RPC, что в REST.
Только в RPC ты их структурируешь по доменам, а не по сущностям, что логичнее.
PD
Хм, а зачем их читать? Там поиск работает. Да и это все занимает меньше секунды.
K
зачем читать джава доки когда есть .нет доки
PD
Ну, я вот с трудом читал доки от MS. К любым докам нужна привычка
СА
Если без сарказма, то опять же отталкиваясь от задачи. Пришёл из соседней команды человек с какой-то проходной задачей. REST: тебе нужна ручка /users/ , дальше по ресту, вот OpenAPI. RPC: тебе нужен раздел документации "Пользователи", там 30 глаголов, разберёшься. Вот файл Open RPC размером мегабайт.
СА
Это когда знаешь, что нужно. А есть моменты, когда надо сперва понять, что оно вообще умеет.
СА
(но мы опять отвлекаемся)
PD
Хм, с чего бы. Тебе нужно в users, вот тебе openApi. Ровно то же, методов не больше (на самом деле для rpc подхода документация обычно короче), инструменты те же.
PD
А для этого обычно не конструкторы важны )
СА
Не люблю объяснять шутки, но она была именно в этом: пока дочитаешь до списка методов (которые и интересовали в первую очередь) - уже можно перерыв сделать.
PD
Ну, странная шутка. Не нужно читать то, что не требуется.
S
...ну если они плоским списком....
PD
И, если кто еще не нашел, про GET+body:
https://stackoverflow.com/questions/978061/http-get-with-request-body
Довольно исчерпывающе )
https://stackoverflow.com/questions/978061/http-get-with-request-body
Довольно исчерпывающе )
AB
Я пишу на дотнете или джаве какой, для меня снижение когнитивной нагрузки - написать апдейт вида _apiClient.UpdateObjectAsync(new UpdateObjectDto { Id = 42, State = newState }); и не мучить себя и всех остальных тем что айди надо в путь положить, остальное в боди, никакой, никакой мне как клиенту выгоды не дает id в пути, кроме того что приседаний в коде больше.
AB
А при наличии redoc/swagger ui мне вообще всё равно куда и как тыкать данные в апи, форма то передо мной
AB
И деление по сущностями/областям никак не связано с path в api, в смысле на доки влияние "как автор доку написал"
СА
На ресте это выглядит примерно так же: APIClient.UpdateObject(42, new UpdateObjectDTO({state = newState })) UpdateObject транслируется в вызов PATCH /object/:id
AB
Мне когда то понравился пример с тем что есть путь типа api/entity/{entityId}/{subEntityId} и нет у меня на странице subEntityId идентификатора entityId, но автор апи считал что должно быть, кто вот его просил так думать - хз (пример выдуманный, т.е. не из продакшен апи, а из попытки rest сделать)