What are RESTful APIs

REST (Representational State Transfer) is an architectural style for designing APIs that relies on using standard HTTP methods to access resources via URLs. Some key principles of REST API design include:

• Resources are identified by URLs, allowing clients to easily locate and modify them using HTTP GET, POST, PUT, DELETE requests. Resources can be documents, images, or any object managed by the service.
• Representations of resources are transferred, most commonly JSON or XML. The representation contains data about the resource's state at the point when the request is made.
• Communication is stateless - no client context is stored on the server between requests. Each request has all necessary information to process it without relying on previous exchanges. This improves scalability and resilience.
• Standard HTTP methods are used to manipulate resources (GET, POST, PUT, DELETE) in a predefined way, easing implementation.
• Self-descriptive error messages allow clients to resolve issues themselves without needing out-of-band information.

Architectural Style - REST is an architectural style with constraints around having a uniform interface, being stateless, using resources & representations, etc. Other API approaches like RPC or SOAP are more freeform without a defined style.

HTTP as Interface - REST uses the building blocks of web architecture like HTTP methods, URIs, headers, body and status codes as the interface to access resources. RPC APIs expose a large number of custom methods more tailored to app internals.

Resources as Nouns - In REST, every entity exposed is modeled as a resource represented by URIs. Resources represent nouns and collections of nouns. In RPC, the calls focus more on exposing verbs or functions directly to manipulate data.

Statelessness - REST treats each request as independent without managing session state between messages. This improves scalability and resilience. RPC protocols track state across multiple requests, not as horizontally scalable.

Caching Support - Built-in HTTP caching mechanisms can be applied to improve REST performance since requests are independent. Custom RPC protocols require proprietary caching to optimize.

Self-Descriptive Messages - REST uses status codes, MIME types and headers so responses contain metadata describing payload format, errors, etc. RPC protocols embed this metadata within message arguments requiring custom parsing.

In summary, REST enforces architectural constraints that embraces and leverages key web technologies to simplify distributed client-server interactions at scale while RPC focuses less on a uniform style and more on exposing application internals.

RESTful APIs are commonly used in web and mobile applications to retrieve or modify resources and data on remote systems. Some examples include:

• Social media sites like Twitter, Facebook use REST APIs to integrate with third-party applications and allow posting updates.
• Ridesharing apps like Uber and Lyft use REST APIs to coordinate cars, obtain maps, fares and location data.
• Video, music streaming through Netflix, Spotify use REST APIs to get info on media files from servers.
• Banking apps utilize REST APIs to retrieve your account data and initiate transactions with remote servers.
• IoT apps interface with sensors and devices via REST APIs to monitor them and send commands.

Overall, REST integrates modern applications with web services due to its simplicity and scalability.

RESTful principles - RESTful APIs adhere to constraints around having a uniform interface, being stateless, exposing directory structure-like URIs, and transferring XML, JSON or other representations of resources.

Resource Identification - Every entity that can be manipulated or accessed in the API is represented as an HTTP resource exposed at a URI endpoint. URIs identify collections, elements, attributes etc.

HTTP Methods - REST uses standard HTTP methods to define interaction with resources. GET retrieves representations, POST creates resources, PUT updates them, DELETE deletes them.

Request Messages - Clients send requests to REST API endpoints with HTTP headers containing metadata like authorization tokens, content-type, accept headers etc. Parameters help filter result sets or bind data.

Response Messages - Servers return HTTP response codes indicating outcomes along with response headers describing the content. The message body contains representations of resources or data payloads.

Statelessness - Each RESTful request is stateless and self-contained without reliance on server context or previous interactions. Sessions maintained via tokens.

Caching Support - REST APIs improve performance by caching repetitive resource representations on the server or client, as HTTP is cacheable.

Self-documentation - REST APIs use HTTP conventions for response codes, verbs, and media types so APIs self-document how they are supposed to be used by clients.

A typical REST endpoint would look like:

GET https://api.example.com/users/1234

Here the endpoint resource is the user with id 1234. The base URL section identifies the REST API server while users path indicates it is a user resource.

Common patterns for REST endpoint URLs:

• /users - Manage user accounts

• /posts - Access blog posts

• /devices/{deviceId} - Handle individual IoT devices

• /reports?type=sales - Filter report collection

So endpoints leverage URL paths and queries to model data access in an intuitive way.

There are a few common methods used to implement authentication and authorization in RESTful APIs:

• API keys - Pass API key string in request header which identifies the caller. Easy to implement but less secure.
• Basic auth - Encode username & password into an Authorization header which the server decodes and verifies. Transmitted unencrypted so weak security.
• OAuth 2.0 - An open standard where access tokens indicate user identity and permissions. Provides secure delegated access.
• OpenID Connect - An identity layer built on OAuth 2.0 which allows third-party login using federated identity providers like Google, Facebook etc. Provides convenience and security.

Additionally certificate based systems like mutual TLS authentication both client and server machines through digital certificates.

SOAP and REST take fundamentally different approaches for building web services. SOAP is a protocol with many built-in specifications around XML messaging formats, service descriptions, transactions, security mechanisms, and more. It allows exposing operations that can be called via strongly-typed XML requests and responses. SOAP services are formally defined via WSDL documents that describe each operation in detail. This provides robust tooling but also more complexity.

In contrast, REST is an architectural style focused on principles like having a uniform interface, stateless interactions, manipulation of resources via URIs, and transfer of resource representations like JSON/XML between clients and servers. Rather than exposing operations, REST accesses named resources in a manner similar to accessing files in a directory structure. By focusing on architectural constraints for scalability rather than specifications, REST aims for simpler and lighter-weight integrations.

Due to lower complexity and easier internet-friendly JSON integrations, REST has seen higher adoption for mobile and web applications connecting to microservices. Development is faster and bandwidth needs lower. SOAP's sophisticated tooling can still suit complex enterprise integration scenarios and workflows better. But for productivity and reach, REST delivers what modern applications need. It emphasizes simplicity in a manner that scales to internet-sized audiences.

Simplicity
REST APIs build on top of HTTP using its standard methods and error codes. This allows very simple client implementations to access web services without complex libraries or tools. The stateless request model further simplifies scaling on the server side. The end result is simplicity across client, server and network for integration.

Flexibility
REST does not enforce or favor any particular data format like XML or JSON. Different representations can be used for transferring resource representations. Developers have great flexibility in modeling resources and leveraging various serialization formats appropriately. This facilitates evolution over time as well.

Scalability
The stateless request model where each request has all the necessary information makes REST interactions highly scalable. Adding more servers is easy since no state needs replicating across nodes. This scale-out nature is essential for large internet audiences and mobile devices.

Performance
Built-in support for caching of resources boosts performance while reducing server loads. Content delivery networks can cache data closer to clients also. And multiple domains can serve REST APIs independently for better resilience.

Portability
REST uses ubiquitous HTTP and JSON making it portable across programming languages/platforms like JavaScript, Java, .NET, Android, iOS etc. This simplifies building polyglot systems where various components are implemented in different languages.

When creating REST APIs, developers should follow certain standard constraints to ensure RESTful design:

• Client-Server - Clear separation of concerns between API client and server. Helps modularize the interface.
• Statelessness - No client context preserved on server between requests. Each request has complete details needed to service it without relying on stored state data. Boosts scalability through horizontal scaling while easing server updates. Requests should be atomic operations when possible.
• Cacheability - REST responses should ideally have cache directives to identify cacheable resources. Caching improves performance and resiliency. Versioning also avoids client breaking changes.
• Uniform Interface - Utilizing standard HTTP operations (GET, POST, PUT, DELETE etc.) on resources keeps the API interface consistent across services. Resources uniquely identified using URIs.
• Layered System - REST allows layered network topology with components like firewalls, load balancers without affecting the interface between clients and servers. Improves scalability.

A typical workflow for building a new RESTful API service involves:

1. Identifying key resources the API needs to expose based on the target application use cases. Resources are real-world entities like accounts, products catalogs etc.
2. Assigning unique resource identifiers to each resource. Usually done by modeling resources into URL routes like /users, /accounts. Resources can have nested hierarchy via routes like /customers/1234/orders
3. Choosing common HTTP methods for operating on resources - e.g. GET, POST for retrieval and creation of resources respectively. DELETE can remove resources.
4. Selecting a data representation format like JSON or XML for transferring resource state back and forth. JSON is most popular choice.
5. Designing API request and response schemas, typically for JSON payloads. Can utilize schemas like OpenAPI Specification to formally define schemas.
6. Implementing resource route handlers in chosen language like Node.js, Java for operations like fetching data from database and returning formatted responses.
7. Adding authentication, rate limits, caching and documentation for API.
8. Testing the API interface thoroughly before release. Gather user feedback for future iteration.

Summary

RESTful APIs offer an easy yet powerful method for building scalable web service interfaces. By constraining architecture around central resources accessed using standard HTTP methods, REST eases connected application development for mobile and web programming. Robust tooling combined with scalability make comprehensive RESTful design central to modern APIs. As needs evolve, REST’s flexibility helps sustain API usability over time.