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
References
- RFC 2616 / 7230–7235 (HTTP)
- SOAP 1.2 Specification
- JSON-RPC Specification
