Definition
REST (Representational State Transfer) is an architectural style for designing web APIs. A REST API exposes resources (users, orders, products, invoices) as URLs and uses standard HTTP methods to perform operations on them. GET retrieves a resource. POST creates one. PUT or PATCH updates one. DELETE removes one. Each request is stateless, meaning the server does not store session information between calls. The client includes all necessary context (authentication token, parameters) in every request.
Roy Fielding defined REST in his 2000 doctoral dissertation, but the pattern became dominant in the mid-2000s when JSON replaced XML as the standard data format and web services moved away from the complexity of SOAP. Today, REST is the default API design pattern for web and mobile applications. Stripe, Twilio, GitHub, and Shopify all offer REST APIs that serve as industry benchmarks for developer experience.
A typical REST API interaction: a mobile app sends GET /api/v1/users/123 to fetch a user profile. The server responds with a JSON object containing the user's name, email, and account status. To update the user's name, the app sends PATCH /api/v1/users/123 with a JSON body containing the new name. The URL identifies the resource. The HTTP method identifies the action. The response includes a status code (200 for success, 404 for not found, 422 for validation errors) that tells the client what happened.
Why It Matters for Product Managers
If your product has a public API, mobile apps, single-page web apps, or third-party integrations, REST API design is a product concern. The API is the interface that external developers, partners, and your own frontend teams interact with daily. Poorly designed endpoints create friction, increase support load, and slow down integration timelines. Well-designed endpoints accelerate adoption and reduce time-to-value for API consumers.
PMs should care about three aspects of REST API design. First, versioning strategy: how do you evolve the API without breaking existing integrations? URL versioning (v1, v2) is the most common approach. Second, pagination: how do clients retrieve large lists of resources efficiently? Cursor-based pagination scales better than offset-based for large datasets. Third, error handling: do your error responses give developers enough information to fix their integration, or do they just say "400 Bad Request"? These decisions affect developer satisfaction, which is a form of user experience.
How to Apply It
When your team is designing or extending an API, the PM should be involved in defining the resource model (what entities does the API expose?), the access patterns (what queries do clients actually need?), and the business rules (which operations require which permissions?). Review the API-first design approach where the API contract is defined before the implementation, allowing frontend and backend teams to work in parallel. Use tools like the PM Tool Picker to evaluate API documentation platforms (Swagger, Postman, ReadMe) that make your API easier for partners to adopt.