Я разрабатываю CorDapp, который потребует ввода данных пользователем, а также интеграции API, и я рассматриваю различные подходы для представления потоков и запросов к хранилищам внешнему миру.
Кажется, используется опция по умолчанию Corda RP C. Если я не пропустил что-то, для него есть только Java привязок, что фактически ограничивает клиентов только на основе JVM. Это несколько неудобно, и в идеале я хотел бы, чтобы что-то вроде OpenAPI сделало его более открытым и независимым от реализации c.
Другой вариант - использовать какой-то Corda RP C для прокси OpenAPI. Я знаю о Брейде, и я уверен, что есть и другие. Похоже, что Braid поддерживает развертывание как сервис Corda, упакованный вместе с потоками в самом CorDapp, что делает его работу встроенной в Corda JVM.
Braid также может быть развернут как автономный прокси-сервер, что, как я полагаю, является опцией три.
Инстинктивно я считаю встроенный режим более привлекательным, так как он уменьшает количество движущихся частей, в отличие от автономного режима. Тем не менее, я обеспокоен тем, что в какой-то момент такая модель может на самом деле обескураживаться, либо потому, что разработчики Corda считают ее средством злоупотребления службами, либо потому, что некоторые организации не будут заинтересованы в развертывании такого кода на своих узлах, особенно когда они могут работать несколько CorDapps. Я полагаю, что все, что развернуто как часть Corda JVM, по крайней мере потребует более тщательного изучения из-за потенциального воздействия на другие работающие там вещи, что, в свою очередь, снизит гибкость.
Интересно, какой подход к интеграции с CorDapp является на самом деле рекомендуется?
Редактировать 1 : я знаю, что технически возможно встроить веб-сервер в узел и предоставить оттуда REST API, по крайней мере, в текущей версии Corda (4.3 в время написания). Вопрос больше в том, стоит ли это делать или нет, и почему.