Activity 28: Research Rest API

What is REST API

REST is an acronym for REpresentational State Transfer and an architectural style for distributed hypermedia systems. Roy Fielding first presented it in 2000 in his famous dissertation. Since then it has become one of the most widely used approaches for building web-based APIs (Application Programming Interfaces).

REST is not a protocol or a standard, it is an architectural style. During the development phase, API developers can implement REST in a variety of ways.

Like the other architectural styles, REST also has its guiding principles and constraints. These principles must be satisfied if a service interface has to be referred to as RESTful.

Six guiding principles of REST

• REST is based on some constraints and principles that promote simplicity, scalability, and statelessness in the design. The six guiding principles or constraints of the RESTful architecture are:

1.1 Uniform Interface

By applying the principle of generality to the components interface, we can simplify the overall system architecture and improve the visibility of interactions.

The following four constraints can achieve a uniform REST interface:

• Identification of resources – The interface must uniquely identify each resource involved in the interaction between the client and the server.

• Manipulation of resources through representations – The resources should have uniform representations in the server response. API consumers should use these representations to modify the resource state in the server.

• Self-descriptive messages – Each resource representation should carry enough information to describe how to process the message. It should also provide information of the additional actions that the client can perform on the resource.

• Hypermedia as the engine of application state – The client should have only the initial URI of the application. The client application should dynamically drive all other resources and interactions with the use of hyperlinks.

1.2 Client Server

The client-server design pattern enforces the separation of concerns, which helps the client and the server components evolve independently.

By separating the user interface concerns (client) from the data storage concerns (server), we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.

While the client and the server evolve, we have to make sure that the interface/contract between the client and the server does not break.

1.3 Stateless

Statelessness mandates that each request from the client to the server must contain all of the information necessary to understand and complete the request.

The server cannot take advantage of any previously stored context information on the server.

1.4 Cacheable

The cacheable constraint requires that a response should implicitly or explicitly label itself as cacheable or non-cacheable.

If the response is cacheable, the client application gets the right to reuse the response data later for equivalent requests and a specified period.

1.5 Layered System

The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior. In a layered system, each component cannot see beyond the immediate layer they are interacting with.

A layman’s example of a layered system is the MVC pattern. The MVC pattern allows for a clear separation of concerns, making it easier to develop, maintain, and scale the application.

1.6 Code on demand (Optional)

REST also allows client functionality to extend by downloading and executing code in the form of applets or scripts.

The downloaded code simplifies clients by reducing the number of features required to be pre-implemented. Servers can provide part of features delivered to the client in the form of code, and the client only needs to execute the code.

REST APIs (Representational State Transfer APIs) are widely used in software development, particularly for web and mobile applications, to facilitate seamless communication between a client (frontend) and a server (backend).

• Social Media Integration: When a mobile app like Twitter's client app requests data such as a user's tweets, it sends a GET request to Twitter’s REST API endpoint (e.g., /api/tweets/user123). The API then responds with the user's tweets in JSON format, which the app displays. Similarly, if a user posts a new tweet, the app sends a POST request, and the server creates this new resource on Twitter's backend

• E-commerce Apps: Many e-commerce web and mobile applications use REST APIs to manage data like product listings, inventory, and user orders. For example, a user browsing products can see real-time inventory levels because the app makes GET requests to an API. When a user places an order, the app sends a POST request to the API, creating a new order record on the server

• Weather Applications: In weather apps, a REST API can be used to fetch the latest weather information based on a location. The app sends a GET request to an external weather API and then displays the forecast based on the received JSON data

Additionally, search best practices for implementing REST APIs on angular

• Use HttpClient Module: Angular’s HttpClient module simplifies making HTTP requests. Always import it in the AppModule and inject it into services for reusable and clean API calls

• Implement Error Handling: Use catchError from RxJS to handle errors gracefully, and log or display them appropriately. This ensures that users receive useful feedback instead of broken or blank screens

• Optimize for Performance: Use RxJS operators like debounceTime and switchMap to reduce API calls, especially in search or filtering features. This improves performance and reduces server load

• Secure Sensitive Data: Avoid exposing sensitive data in requests. For example, keep tokens and keys in environment files and use Angular’s HttpHeaders to attach these securely

Some references: https://restfulapi.net/