英文:
Access chaincode/smartcontract methods on hyperledger fabrix 2.4 as REST endpoints
问题
在Hyperledger Fabric 2.4上将链码/智能合约方法暴露为REST端点
大家好，是否可以将在Hyperledger Fabric测试网络的通道上部署的链码/智能合约方法暴露为REST端点，以便在我正在开发的前端上使用？
如果可以，如何操作？是否有我可以参考的文档？
我正在Windows机器上的WSL2上运行测试网络。
我已经成功部署和实例化了通道上的链码，并通过CLI运行了调用和查询方法。我想将它们暴露为REST API，以便在我的前端Web应用程序中使用。
英文:
Access chaincode/smartcontract methods on hyperledger fabrix 2.4 as REST endpoints
Hello all, is it possible to expose the chaincode/smart contract methods, which was deployed on a channel in hyperledger fabric test-network as REST endpoints to use on a frontend which I am working on?
If yes, how can one do it, are there any references which I can use?
I am running the test-network on wsl2 on a windows machine
I have been able to deploy and instantiate the chaincode on the channel and run the invoke and query methods through the CLI.
I want to expose them as REST API so that I could use them in my front-end web application
答案1
得分: 1
- 你可能需要采取的方法是编写一个应用程序，同时完成以下两个任务：
- 向REST客户端提供适当的REST API；
- 在收到REST请求时，使用Fabric客户端API与Fabric进行交互。
这种方法的示例在full-stack-asset-transfer-guide Fabric示例中有提供。根据您的需求，您可能需要比该示例中演示的更全面的错误处理。在相同示例的应用程序开发文档中有一个简单的错误处理行为示例。
还有一个重要的考虑因素是与Fabric互动时将使用的加密身份。您的选择要么是：
- 为客户端应用程序拥有一个（或多个）身份，并且所有的REST请求都使用该应用程序身份来驱动Fabric调用。
- Fabric交互使用由每个REST客户端拥有的身份。
如果使用单一的应用程序身份，将重要的是要有某种方式来对REST客户端进行身份验证。您可能需要考虑记录谁在做什么的审计。
如果REST客户端拥有自己的加密身份，他们将希望将私钥保持私有，不与您的REST应用程序共享。这意味着发送到Fabric的消息必须由REST客户端使用私钥签名，而不是由您的REST应用程序签名。实现这一点的一种方法是“离线签名”，其中REST应用程序构建Fabric请求，将消息（或只是其摘要/哈希）返回给REST客户端进行签名，然后将这个由客户端生成的签名附加到发送给Fabric的消息中。在API文档中有关于这种方法的简要概述和代码示例。
英文:
The approach you probably need to take is to write an application that both:
- Exposes an appropriate REST API to REST clients; and
- Interacts with Fabric using the Fabric client APIs when REST requests are received.
There is an example of this approach within the full-stack-asset-transfer-guide Fabric sample. Depending on your requirements, you might want to implement more thorough error handling than is demonstrated by that sample. There is a simple example of error handling behaviour in the application development documentation of the same sample.
One more important consideration is the cryptographic identity that you will use to interact with Fabric. Your options are either:
- Have one (or more) identity for the client application, and all REST requests drive Fabric invocations using this application identity.
- Have Fabric interactions use identities owned by each REST client.
If using a single, application identity, it will be important to have some means of authenticating your REST clients. You might want to consider audit of who is doing what.
If the REST clients have their own cryptographic identity, they will want to keep their private keys private and not share them with your REST application. This means that messages sent to Fabric must be signed (using the private key) by the REST client, not your REST application. A pattern for achieving this is "off-line signing", where the REST application builds the Fabric request, returns the message (or just its digest/hash) to the REST client to sign, then attaches this client-generated signature to the message sent to Fabric. There is a brief overview of this approach with code examples in the API documentation.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论