В публикуемом наружу API есть стандартные методы для коммуникации со смежными системами подобного класса, для добавления нового подписчика в брокер надо лишь добавить техническую учетную запись пользователя в ролевую модель на стороне брокера или очереди, почле чего статьи и сообщения публикатора так же могут быть вычитаны из очереди подписчиком.
Необходимо внедрять слой API-Management'а, дабы управлять политиками и синхронизировать все эти распределенные коммуникации
Протоколом HTTPS пользуются мало, пароли передают по протоколу Basic, пароли часто не в криптованом Base64, а хранят plain-text'ом прямо в открытом виде, передают в виде стринги прямо в HTTP-заголовке, замечено даже хранение прямо внутри JSON-структуры как Key-Value
Внутреннее API изменчиво, видны признаки псевдо-интеллекта, созданного на гроздьях и связках If-Then-Else логики и кучей GoTo-переходов, но маскируется под Data Science и продвинутые алгоритмы машинного обучения, заложенные в библиотеках на Python.
ну не то, чтобы совсем старался, - так - че в кэше в голове было вывалил) А что конкретно не так - про HTTP-заголовки?)
Стрингой пароль в открытом виде можно, думаю, умудриться запихнуть, а потом обработчиком каким считать - парсеру то какая разница, что за информация в хэдере и его атрибутах - взял считал и понеслась
Ну к примеру у блондинок там может быть пароль :)
Как такового https, как отдельного протокола нет, это не отдельный протокол, а http внутри ssl. Пароли в хедере, это ты про параметры url? Или в куках? Или в своëм отдельном поле? А если не get, а post, или put использовать? Но как клюква в общем контексте - не плохо
:) я знаю, что такое HTTPS, хоть уже не разраб и не админ давно :)
Не, не про параметры и не про методы, и даже не про GET/PUT как таковое, и ж тем более не про куки
Смотри, на примере интеграционного приложения на Java - допустим я интегрирую APP1 с APP2, причем APP2 имеет количество инстансов.
APP1 является инициатором взаимодействия и шлет XML-пакет. Задача APP1 так же указать конкретный инстанс APP2, куда передать - и он в HTTP-заголовке может сделать кастомный атрибут, назвать его, к примеру DestinationKey, а как значение - какую-то метку, понятную интеграционному приложению, к примеру - LocationID, CompanyID и прочее
Задача медианной логики интеграционного приложения - вычитать это сообщение, раскрыть конверт, увидеть в хэдере рядом с payload'ом этот самый кастомный атрибут, вычитать значение атрибута, и построить точный маршрут до эндпойнта-получателя.
К примеру - это будет банальный SWITCH в SpringDSL нотации для Apache Camel'а.
Это в общем-то паттерн "Router"
Ну и понимая, что в хэдер мы можем пихнуть любую кастомную фигню - я типо прикольнулся, что нерадивый разработчик-блондинка туда может пихнуть UserPassword Открытым текстом :)
Обычно же в заголовке или UserId или Токен передаются, а пароль криптуется по Base64, если это протокол Basic
По большому, я докапался до https, как до отдельного протокола. Скорее всего, из-за того, что свой путь в IT, я начал с детального разбора протоколов обмена данными, модель OSI итд итп. А потом, после всей этой четкой и логичной структуры, жизнь меня макнунла в PHP :), хотя перед этим, я уже давно писал на С и С++.... Фантомные боли по логике, так сказать.. Подумав немного и вспомнив, что сам использовал кастомные заголовки, как метки идентификации (мне нужно было различать запросы от браузеров и от своего приложения), принимаю концепцию, но только, как для блондинки!
Выбор бекэнда был не простой, останоаились на php, потому что прост в обслуживании и не так требователен, как java. Задача - ну трудно оценить сложность... Нормальная. Пробовали разные технологии, все плюс-минус одинаково показывают производительность, но с пхп проще, в плане развертывания, берешь хостинг и поехал, практически из коробки.
PHP хорош имхо что в условиях наступающего импортозамещения продуктов, по крайней мере в ГосКомпаниях - использовать для 1С Битрикс, который точно еще будет популярен и актуален
Сложности с возвратом по гарантии папе-производителю, не определены чётко критерии возврата в договоре, сам договор в большинстве на словах, техническая документация неполная, user manual'ы надо составлять и узнавать самому
15 комментариев
3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Необходимо внедрять слой API-Management'а, дабы управлять политиками и синхронизировать все эти распределенные коммуникации
Протоколом HTTPS пользуются мало, пароли передают по протоколу Basic, пароли часто не в криптованом Base64, а хранят plain-text'ом прямо в открытом виде, передают в виде стринги прямо в HTTP-заголовке, замечено даже хранение прямо внутри JSON-структуры как Key-Value
Внутреннее API изменчиво, видны признаки псевдо-интеллекта, созданного на гроздьях и связках If-Then-Else логики и кучей GoTo-переходов, но маскируется под Data Science и продвинутые алгоритмы машинного обучения, заложенные в библиотеках на Python.
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Стрингой пароль в открытом виде можно, думаю, умудриться запихнуть, а потом обработчиком каким считать - парсеру то какая разница, что за информация в хэдере и его атрибутах - взял считал и понеслась
Ну к примеру у блондинок там может быть пароль :)
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Не, не про параметры и не про методы, и даже не про GET/PUT как таковое, и ж тем более не про куки
Смотри, на примере интеграционного приложения на Java - допустим я интегрирую APP1 с APP2, причем APP2 имеет количество инстансов.
APP1 является инициатором взаимодействия и шлет XML-пакет. Задача APP1 так же указать конкретный инстанс APP2, куда передать - и он в HTTP-заголовке может сделать кастомный атрибут, назвать его, к примеру DestinationKey, а как значение - какую-то метку, понятную интеграционному приложению, к примеру - LocationID, CompanyID и прочее
Задача медианной логики интеграционного приложения - вычитать это сообщение, раскрыть конверт, увидеть в хэдере рядом с payload'ом этот самый кастомный атрибут, вычитать значение атрибута, и построить точный маршрут до эндпойнта-получателя.
К примеру - это будет банальный SWITCH в SpringDSL нотации для Apache Camel'а.
Это в общем-то паттерн "Router"
Ну и понимая, что в хэдер мы можем пихнуть любую кастомную фигню - я типо прикольнулся, что нерадивый разработчик-блондинка туда может пихнуть UserPassword Открытым текстом :)
Обычно же в заголовке или UserId или Токен передаются, а пароль криптуется по Base64, если это протокол Basic
Как-то так :)
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
а PHP совсем плох, как язык, или задачи были не очень?
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена3 года назад
Удалить комментарий?
Удалить Отмена