Network-Level API (synonymous to OSI’s application-layer protocols) refers to any network protocol used to exchange data between participating parties. These are used to build Application-Level APIs and usually follows an API Design Pattern

see similar page: Browser APIs which includes NON-network-level APIs (e.g. Web AudioWeb Components, etc)

Network-Level APIs

Network-Level APIs

Purpose

Description

HTTP 1.X

bi-directional communication

  • a network protocol
  • distinguishing features:
    • bi-directional communication
    • not full-duplex

HTTP2.0

full-duplex communication

  • a network protocol
  • distinguishing features:
    • full-duplex (it would be possible for the client to communicate to the server by making another request on the same TCP connection, thanks to HTTP/2 multiplexing)
    • no unsolicited communication from server to client, HTTP/2 can “push” a resource to the client ONLY in the context of a previous request

WebSockets

  • a network protocol for full-duplex communication between server and client
  • distinguishing features:
    • full-duplex
    • uses HTTP for initializing and a single TCP connection for communication
    • allows unsolicited communication from server to client (after HTTP initialize)

Reactive Streams

  • a network protocol for full-duplex communication between server and client (with framing, session resumption, and backpressure built-in that works over the network)
  • is transport agnostic (i.e. RSocket can be run over WebSockets, TCP, 2, and Aeron)
  • intended for use in distributed/microservice applications
  • it works in a browser equally as well as on a server. In fact, a web browser can serve traffic to backend microservices

WebRTC

  • peer-to-peer/real-time communication
  • a bundle of network protocol standards for real-time/peer-to-peer communication (natively supported in most browsers) - faster than traditional peer-server-peer communication

RPC (protocol)

  • a network protocol

Network-Level API Comparisons

  • WebSockets vs HTTP
    • both run on top of TCP, WebSockets use HTTP for initial connection setup
    • both allows persistent connections (HTTP Keep Alive)
    • however, only WebSockets supports unsolicited communication from server to client (after HTTP initialize)
  • WebSockets vs RSocket
    • Websockets do not provide application-level backpressure, only TCP-based byte-level backpressure
    • Websockets also only provide framing they do not provide application semantics. It is up to the developer to build out an application protocol for interacting with the websocket
    • RSocket provides framing, application semantics, application-level backpressure, and it is not tied to a specific transport
  • RSocket vs gRPC
    • RSocket works in a web browser via Websockets, while gRPC requires additional code to be generated and deployed in order to work in browser
    • RSocket has application level flow control while gRPC relies on HTTP/2 byte-based flow control