Summary of "Lec 14: REST based Web Services"

REST-based Web Services — Lecture 14

REST (Representational State Transfer) is an architectural style for designing web APIs — it is not a protocol or a data format.

REST models data as resources accessed via URLs and manipulated with standard HTTP methods.
HTTP is the transport/protocol used (requests/responses). JSON is the common data format used in REST APIs (contrasted with SOAP which typically uses XML).
Typical resource URL example: https://api.example.com/resource.
Common HTTP methods used in REST:
- GET — retrieve a resource
- POST — create a new resource
- PUT — update or replace a resource
- DELETE — remove a resource

SOAP:
- Is a protocol with a fixed XML envelope and a header/body structure.
- Is often carried using HTTP POST and relies on XML messages.
REST:
- Is a set of architectural guidelines/constraints rather than a protocol.
- Uses resource-oriented URIs and standard HTTP methods.
- Commonly uses JSON (but can use other formats) instead of fixed XML envelopes.

Uniform interface: access resources consistently via HTTP methods and predictable URIs.
Client–server separation: separate concerns between client (consumer) and server (provider).
Statelessness: servers do not keep client session state between requests.
Cacheable: responses should indicate whether they can be cached to improve performance.
Layered system: clients need not know whether they communicate with the final server, a proxy, load balancer, or cache.
Code on demand (optional): servers may provide executable code to clients when needed.

To make an API RESTful:
- Treat every entity as a resource.
- Expose meaningful resource URIs.
- Use appropriate HTTP verbs for actions.
- Return structured JSON payloads.
- Respect statelessness and caching semantics.
Analogy from the lecture:
- REST is the instruction on how to fill a form;
- JSON is the filled form;
- HTTP is the carrier who submits it.