/blocks should allow fetching of multiple blocks

[Swader]

Right now the blocks endpoint (somewhat misleadingly) fetches info for only a single block. It would be good if it supported a comma or plus separated list of blocks, and return them all in an array.

/blocks/500001+500002
or
/blocks/500001,500002

The BC-approach would be to only return as array when multiple blocks are passed in. The right approach would be a mid version bump due to a change in return values which should now ALWAYS return arrays, even when looking for a simple blocks. The single-element return should be renamed to /block and should under the hood just call /blocks/xxxx[0]

[dvdplm]

Why do you think /blocks/BLOCKNUM is misleading? It's a pretty standard REST-style url like e.g. /posts/123 to designate a Post object with id 123.

Renaming /blocks to /block is unlikely to happen.

I do like the idea of supporting a batch of blocks though.

[Swader]

To me blocks implies plural but I agree if you're thinking in REST terms.

[TarikGul]

I do like the idea of being able to query a batch of blocks as well. It would take a little planning, and design but I think it is very doable if done right.

[emostov]

To build on what David is saying: /blocks is a RESTful representation of a collection resource. /blocks/{blockId} is a single resource that belongs-to the collection resource; the current endpoint design advances this model. Since this is explicitly a RESTful service I don't see any problems in how that model is surfaced through api-sidecar's URIs.

What is the use case for a sub-collection of blocks query?

Why is that use case not currently supported by the available endpoints?

[TarikGul]

I think more so than anything this would be looked at as an optimization.

Potentially, a batch endpoint could prevent bottlenecks and increase performance for very large queries. With the upcoming benchmarking too I think it will also give us more insight on the potential capabilities of something like this.

I know that batching is usually associated with making Patch/Post requests for updating/creating a set of any items. But I think in this case for a /GET route it could reduce network overhead, especially if RPC calls to the chain could be made via batches as well.

[Swader]

Exactly this. We have a use case where we have a target of a few dozen blocks at a time, maybe up to a thousand. Being able to define a block range (50000-50550) or multiple blocks (50000,50001,50002) would save us a lot of time and effort in parsing, processing, and ultimately, in stressing the server which is running both the node and the sidecar instance that's connecting to it.

[emostov]

My proposal is that once Tarik establishes some good baselines for benchmarking and we have investigated the low hanging fruit for optimization of the /blocks/{blockId} endpoint, we can then look into add this functionality.

Ideally, prior to merging, we would be able to show this feature has performance benefits over requesting the equivalent set of blocks individually.