View source for How Computers Interact with HTTP Endpoints

= How Computers Interact with HTTP Endpoints =

'''Summary:'''
This article explains how computers programmatically communicate with remote systems using HTTP-based interfaces. It covers common web service approaches including XML-RPC, SOAP, RESTful APIs, and JSON-RPC, explaining how they differ, why they exist, and where each is still encountered in real-world systems.

== Context ==
HTTP is often thought of as a protocol for humans using web browsers. In practice, it is more commonly used for machine-to-machine communication.

When one system needs to:
* submit data to another system
* request information
* trigger a remote action
* integrate with a third-party platform

…it will often do so by sending structured data to an HTTP endpoint.

These interactions are commonly referred to as:
* Web Services
* APIs (Application Programming Interfaces)

While modern systems strongly favour RESTful APIs, older and more formal RPC-style approaches are still widely encountered and must be understood.

== The Basic Interaction Model ==
At a fundamental level, all HTTP-based integrations follow the same pattern:

Client System -> HTTP Request -> Endpoint -> HTTP Response -> Client System

Key points:
* HTTP is the transport
* The payload format defines the service style
* The contract defines what both sides expect

== Web Services vs APIs ==
Historically, the term Web Service implied:
* formal contracts
* strict schemas
* RPC-style method calls

The term API is broader and now usually implies:
* resource-based interaction
* lightweight formats (JSON)
* pragmatic, loosely-coupled design

In practice:
* SOAP and XML-RPC are classic Web Services
* RESTful interfaces are modern APIs
* JSON-RPC sits somewhere in between

== RPC-Style Services ==
RPC-style services treat HTTP as a tunnel for calling remote functions.
The client effectively says: "Run this method with these parameters."

Characteristics:
* Strongly action-oriented
* Message body defines the operation
* Server behaves like a remote object or service

== XML-RPC ==
Key Characteristics:
* Uses HTTP POST
* Payload is XML
* Calls a named method with parameters

Where You’ll See It:
* Legacy systems
* Older CMS platforms
* Internal automation tools

== SOAP ==
SOAP is a formal, standards-driven evolution of RPC-style services.

Strengths:
* Strong contracts
* Formal validation
* Enterprise tooling support

Weaknesses:
* Verbose
* Complex
* Tooling-heavy

== RESTful APIs ==
REST treats HTTP as a first-class application protocol.

Core Principles:
* Resources identified by URLs
* Standard HTTP verbs define actions
* Stateless interactions
* Clear use of HTTP status codes

== Why REST Is Preferred ==
REST aligns naturally with how HTTP already works.
Advantages:
* Simple mental model
* Human-readable
* Easy debugging
* Scales well

== JSON-RPC ==
JSON-RPC brings RPC-style semantics into the JSON world.

Example:
{"method": "getUserDetails", "params": {"userId": 123}}

== REST vs RPC Comparison ==
REST = resource-oriented
RPC = method-oriented

== Common Pitfalls ==
* Treating REST endpoints like RPC calls
* Ignoring status codes
* Overloading POST

== Diagnostics ==
Check:
* HTTP codes
* Headers
* Payload validity

== Related Topics ==
* [[HTTP Status Codes]]
* [[API Authentication Methods]]
* [[REST API Versioning]]

== References ==
* RFC 2616 / 7230–7235 (HTTP)
* SOAP 1.2 Specification
* JSON-RPC Specification