REST API and Web Services Review

## Web Services and APIs - **API (Application Programming Interface)**: A general way for software to communicate with other software. - **Web service**: A specific type of API that uses web technologies like HTTP to exchange data over a network. Every web service is an API, but not every API is a web service. - **Key characteristics of a web service**: runs on a server, enables machine-to-machine communication, is language-agnostic, is platform-agnostic, and uses standard web protocols (HTTP/HTTPS, FTP, SMTP). - **REST (Representational State Transfer)**: The most widely used type of web service today. Exposes resources identified by URL paths like `/users` or `/users/20`. Responses are usually in JSON, but can also be XML or plain text. - **SOAP (Simple Object Access Protocol)**: Uses only XML. Common in enterprise systems that need stricter standards and security. - **XML-RPC**: Uses XML to encode requests and responses. Lightweight but less flexible than REST. - **`Accept` header**: Used by a client to tell the server which response format it wants, for example `Accept: application/json`. ## The REST Architecture - **Statelessness**: Every request must include all the information the server needs to process it. The server does not remember previous requests. - **Resource**: A piece of data that can be accessed or modified, identified by a URL (for example, `/products/1`). - **HTTP methods in REST**: - `GET` — retrieve a resource - `POST` — create a new resource - `PUT` / `PATCH` — update an existing resource - `DELETE` — remove a resource ## HTTP Status Codes After processing a request, the server responds with a **status code** that indicates the result: - `200` **(OK)**: The request was successful - `201` **(Created)**: A new resource was created - `400` **(Bad Request)**: The client sent invalid data - `404` **(Not Found)**: The requested resource does not exist - `500` **(Internal Server Error)**: An error occurred on the server ### How a REST request works 1. The client sends a request with a method, URL, optional headers, and optional body. 2. The server validates the request and identifies the resource. 3. The server performs the action (get, create, update, or delete). 4. The server builds a response with a status code and optional body (usually JSON). 5. The server sends the response — no client state is stored. 6. The client checks the status code and processes the returned data. ## Monoliths vs. Microservices - **Monolith**: A single, large codebase where the UI, database, and API all live together. Works well for small apps but gets harder to maintain and scale as it grows. - **Microservices**: An architecture where a large app is broken into smaller, independent services. Each service handles one business capability (for example, products, orders, payments) and can have its own codebase, database, and team. - **How microservices communicate**: Through APIs or message-based systems. - **Advantages of microservices**: Faster development, better fault isolation, and the freedom to use different languages or frameworks per service. - **Challenges of microservices**: More complex debugging, harder infrastructure management, and more network overhead between services.