RESTful

CRUDing data

• an API design pattern for CRUDing data
• implemented on top of an existing network protocol
• hard/impossible to manage interrelated data in a SINGLE operation

GraphQL

CRUDing data
(relational data)

• an API design pattern for CRUDing data
• implemented on top of an existing network protocol
• easier to manage interrelated data in a SINGLE operation

SOAP

brain fart

• both: an API design pattern & a network protocol
• distinguishing features:
  • security
  • transactions
  • ACID (Atomicity, Consistency, Isolation, Durability) compliance

RPC (architecture)

calling a procedure in another process and exchanging data

• an API design pattern for calling a procedure in another process and exchanging data
• implemented on top of an existing network protocol

RMI

objected-oriented RPC

• an API design pattern similar to RPC (architecture), but takes it a step further by making it object-oriented and providing the capability to keep references to remote objects and invoke their methods
• implemented on top of an existing network protocol

Reactive Streams

streaming data

• used for processing infinite streams of data in an asynchronous and non-blocking manner

WebHooks

subscribers & providers

an API design pattern for subscribers and providers

Client/Subscriber

• client registers subscription endpoint by submitting a Client Callback URL to the Server/Provider
• and then, whenever a new event occurs on the server, the server can send a request to the Client Callback URL to notify the update

Server/Provider has 2 tasks:

• define a subscription endpoint that allows clients to subscribe
• implement a WebHook queue of Client Callback URLs

WebSubs - PubSubHubbub - PubSub - PuSH

subscribers & providers

an API design pattern for subscribers and providers

WebSub is built upon an ecosystem of:

• Servers/Publishers (Medium, WordPress, etc.)
• Mediators/Hubs (Superfeedr, Switchboard, etc.)
• Clients/Subscribers (Feedly, Flipboard, etc.).

Compared to WebHook, WebSub requires way less effort for Publishers as all they need to do is declare the Hub they’re using with the Link Header, and then ping it when they have new content published.

For Client/Subscribers, not much changed as they’re still going to make a subscription request but this time to the Hub, which is going to ping them at its turn when new content has been published.