Extend JSON-RPC transport capabilities for batch requests

[tcoratger]

Extend JSON-RPC Transport Capabilities for Batch Requests

Context

Currently, the JsonRpcRequest structure in

https://github.com/xJonathanLEI/starknet-rs/blob/master/starknet-providers/src/jsonrpc/transports/http.rs

allows for making JSON-RPC requests with a specified method. To support the needs of various RPC services, it would be beneficial to extend the transport capabilities to handle batch requests. This can likely be achieved by improving the JsonRpcTransport trait.

Proposed Changes

1. Enhance JsonRpcTransport Trait:

   • Modify the JsonRpcTransport trait to include a new send_requests method that facilitates sending requests in batch.

2. Introduce JsonRpcRequests Type:

   • Create a new type, JsonRpcRequests, which is essentially a vector of JsonRpcRequest.

The previous two points are suggestions only. Feel free to propose any other way to achieve the same goal in a better way.

Additional Resources

For more details on batch requests, refer to the associated documentation.

[thetheveloper]

Current approach

The @tcoratger idea is a correct approach, however we believe it could be simplified a bit more. Unless there is a specific reason/use case for introducing a new type like JsonRpcRequests, we could just define a vector of JsonRpcRequest. The rest would be the same as suggested in the original Issue description.

Implementation details

For now the function send_requests can be implemented in the JsonRpcTransport struct and called with vector of requests as an argument. It’s easy to pass requests of the same JsonRpcMethod.

Improvement proposal

An improvement to this implementation is up for discussion and a separate issue. In essense, if we want to make a batch request of different RPC methods we need to implement enum of JsonRpcRequest params to allow vector to store different data types.

The general idea would be the following: We introduce an enum type that allows all possible payloads to be passed through the generic type. _The only limitation here would be that whenever there is a new request type, the enum needs to be expanded in the library, which is not very robust - hence just this is a topic for separate discussion.

Summary

If the presented approach in the first 2 paragraphs is compatible with the lib, we already have the code working and we would like to share it in a new PR to be verified by the @xJonathanLEI