4 ms·

Ask HN: What Is the Equivalent of These API and Protocols for Non-Browsers?

• niftich 10y ago
  Non-browser alternatives for all the things listed above websocket: some application-layer protocol running on top of TCP. Non-browser alternatives for websocket: TCP Specifically, you're looking for messaging protocols like AMQP, MQTT, XMPP, STOMP, or even HTTP because there are other HTTP clients than just the ones inside browsers. All these protocols describe some aspects of framing and semantics, and predictably, you need both a protocol-client and a protocol-server to run them. Stuff like SNS and GCM is Messaging-as-a-Service, where they host the server, and give you a client to integrate into your code.
  • kevindeasis 10y ago
    Brilliant, thanks for this! I'll go check them out.
    • niftich 10y ago
      I should expand my point by saying that all the XHR stuff and Server-Sent Events are simultaneously Javascript APIs exposed in the browser's script context, but also techniques/"protocols" that an HTTP client can implement by adhering to a specific behavior. For example, any HTTP client can receive server-sent events in the wire-level HTTP sense, like curl [1], which will just print all data being streamed to it until you abort; but it doesn't provide an API equivalent to the onMessage semantics like you get in the browser. To understand the distinction, see this github issue about adding "support" for Server-Side Events for another HTTP client here [2]. If your HTTP client library of choice doesn't provide the semantics you want, you may be able to build them in yourself. [1] http://stackoverflow.com/questions/31238626/ http://stackoverflow.com/questions/31238626/ [2] https://github.com/square/retrofit/issues/1029 https://github.com/square/retrofit/issues/1029