What Is a REST API? RESTful Design Principles
REST (Representational State Transfer) is an architectural style for designing networked APIs, originally described by Roy Fielding in his 2000 dissertation. A REST API uses HTTP URLs to identify resources and standard HTTP methods (GET, POST, PUT, PATCH, DELETE) as actions. The majority of public APIs today are built on REST principles.
The Six REST Constraints
Client-Server: separation of concerns between UI and data. Stateless: each request contains all necessary context; no session state on the server. Cacheable: responses should declare whether they are cacheable. Uniform Interface: resources identified by URIs, manipulated via representations, with self-descriptive messages and HATEOAS (hypermedia as the engine of application state). Layered System: client cannot tell if it is connected directly to the server. Code on Demand (optional): server can send executable code.
URL Design Best Practices
Use nouns not verbs: /articles (not /getArticles). Use plural nouns for collections: /users, /orders. Nest for hierarchy: /users/42/orders/7. Use query params for filtering: /articles?category=tech&page=2. Return 201 + Location header after POST. Use 204 No Content for successful DELETE. Version via URLs (/v1/) or Accept headers — both common, URL is simpler to debug.
REST vs GraphQL vs gRPC
REST: simple, widely understood, excellent caching. GraphQL: client-specified queries, single endpoint, great for complex data graphs, poor native caching. gRPC: binary protocol (Protocol Buffers), 5–10× faster than JSON REST for service-to-service calls, strongly typed contracts, poor browser support without a proxy. Most public consumer APIs use REST; most internal microservice traffic uses gRPC.