Le operazioni batch possono essere molto utili: una singola richiesta tende ad essere più veloce di fare richieste multiple una dopo l'altra. In particolare, la velocità di una richiesta è limitata dal throughput della connessione Internet e dalla latenza (tempo di attesa). Le richieste in batch aiutano con entrambi, ma in gran parte eliminano la latenza per richiesta perché devi solo aspettare una singola risposta.
Tuttavia ci sono alcuni grossi problemi con le richieste batch: ora devi considerare i casi in cui alcune ma non tutte le singole richieste hanno successo. Inoltre, potresti non essere in grado di utilizzare l'URL per il routing, se la richiesta batch può contenere singole richieste per endpoint API.
Quindi, quello che succede è che o re-inventate il vostro protocollo RPC e di trasporto, o dovete usare un protocollo esistente come SOAP o GraphQL. Questo non è necessariamente negativo, questo è solo uno stile API completamente diverso da quello che viene utilizzato da HTTP. In un caso estremo, tutte le richieste API vengono impacchettate come richieste POST allo stesso URL e le azioni reali sono determinate da un documento JSON o XML nel corpo della richiesta.
La maggior parte dei framework web non anticipa tali API e non può aiutarti a costruirla.
Ma tutto ciò potrebbe non essere necessario. Il tuo sviluppatore di app può già inviare più richieste in parallelo (non aiuterà con il throughput ma elimina anche una certa latenza). I moderni standard HTTP riducono anche la latenza. Le connessioni HTTP / 1.1 possono essere riutilizzate per più richieste e le connessioni HTTP / 2 possono multiplexare più richieste sulla stessa connessione.
Con HTTP / 2 non ha senso offrire API batch perché le singole richieste sono altrettanto efficienti, senza dover utilizzare un protocollo diverso. Per motivi simili, HTTP / 2 rende inoltre superfluo combinare piccole icone in un'immagine "sprite" più grande durante la progettazione di un sito Web.