I've now added a batch load endpoint called getledgerentrybatch. This is a POST method and requires the following body:

ledgerSeq=NUM&key=Base64&key=Base64...

ledgerSeq is an optional value that follows the same semantics as the getledgerentry endpoint. It is followed by one or more key to be queried. The return value is a JSON payload as follows:

{
"entries": [
  {"entry": "Base64-LedgerKey", "state": "dead"}, // dead entry
  {"entry": "Base64-LedgerEntry", "state": "live"}, // live entry
],
"ledger": ledgerSeq
}

If a ledgerSeq is queried but is not available, the return payload is as follows:

{"ledger": ledgerSeq, "state": "not_found"}

I know this is just a prototype, but it would be more ergonomic to send JSON in the POST body..

Also, from the example response it seems like "entry" could point to both an entry or a key, I would suggest always providing a key and optionally providing an entry field which can be omitted, as follows:

{
"entries": [
  {"key": "Base64-LedgerKey", "state": "dead"}, // dead entry
  {"key": "Base64-LedgerKey", "entry": "Base64-LedgerEntry", "state": "live"}, // live entry
],
"ledger": ledgerSeq
}

Regarding:

{"ledger": ledgerSeq, "state": "not_found"}

Could you simply use a 404 HTTP status code instead?

Additionally, how can I distinguish TTL'ed entries? Are TTL'ed entries the ones with "dead" status? I will also need the entry body for TTL'ed entries.

To be clear, what I need is a way to implement SnapshotSourceWithArchive from the endpoint you provide.

Additionally, how can I distinguish TTL'ed entries? Are TTL'ed entries the ones with "dead" status?

I will need the entry for those as well.

If an entry has been evicted, it will be reported as DEAD. If the entry is expired but not evicted, it will be returned as LIVE. This is just a raw key-value lookup that doesn’t enforce TTLs. To determine if a key is dead or not, you’ll need to load both the entry key and the TTL key. Here, live means “the key exists on the BucketList” and dead means “key does not exist on the BucketList” and is unrelated to TTL. I believe this is the same interface as your get_including_archived.

Ah, ok, so live means not evicted (but possibly expired), and I need to query TTL entries separately (the more reason to have a batch endpoint)

If "dead" means not found, we can simply omit those entries and assume omitted entries where not found.

Then we can get rid of the state field altogether (since present entries are implicitly live)

What is the maximum number of ledger entry keys this endpoint could accept?

What is the maximum number of ledger entry keys this endpoint could accept?

I haven't tested the maximum entries for a single query. However I doubt it will be a limiting factor, given we achieved a request rate of 20k RPS with an average latency of 548.105 us for point loads, and bulk loads are more efficient.

@SirTyson We currently support 200 keys which is more than sufficient.
Btw the current interface is here and I hope this is a non-breaking change for downstream clients: https://developers.stellar.org/docs/data/rpc/api-reference/methods/getLedgerEntries

@janewang this endpoint will not be directly exposed to clients. This is the backend that rpc will call, so if more encodings or other protocols/semantics need to be supported in clients this would be done in rpc not core.

LGTM, could you please rebase and squash?

LGTM, could you please rebase and squash?

Done

All your comments should be addressed @Shaptic