What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:
To have a safe online information exchange between two computer it's needed an interface, one of then is RESTful API. To carry out various duties, the majority of business apps must interface with other internal and external applications. For instance, in order to automate invoicing and connect with an internal services application. This information exchange is supported by RESTful APIs because they adhere to safe, dependable, and effective standards for software communication.
An application programming interface (API) defines the rules that you must follow to communicate with other software systems. Developers expose or create APIs so that other applications can communicate with their applications programmatically. Usually there is an client and a resource that the client aim to retrive.
Clients: that seek to access information via the web are referred to as clients. The client, who makes use of the API, might be a person or a piece of software.
Resources: are the details that various programs give their users. Resources can be any kind of data, including text, numbers, photos, videos, and so on. The device that provides the client with the resource is also referred to as the server. While retaining security, control, and authentication, businesses use APIs to share resources and offer web services. They can also choose which customers have access to particular internal resources with the aid of APIs.
A software architecture called Representational State Transfer (REST) places restrictions on how an API should operate. REST APIs are APIs that adhere to the REST architectural design. RESTful web services are online services that use the REST architecture. RESTful web APIs are commonly referred to as RESTful APIs. REST API and RESTful API can, however, be used interchangeably.
Because REST optimizes client-server interactions, systems that employ REST APIs can grow effectively. Because the server does not need to keep track of previous client requests, statelessness reduces server burden. Some client-server interactions are reduced or eliminated entirely by properly managed caching. All of these aspects enable scaling without creating performance-degrading communication bottlenecks.
Total client-server separation is supported by RESTful web services. In order for each server component to develop independently, they disconnect and simplify the numerous server components. Changes to the server application's platform or technology have no impact on the client application. Flexibility is further increased by the option to overlay application features. For instance, developers don't need to rewrite the application logic to make changes to the database layer.
Regardless of the technology being used, REST APIs work. Different programming languages can be used to create client and server apps without changing how the API is designed. On either side, the underlying technology can be changed without impacting communication.
A RESTful API performs the same fundamental task as accessing the internet. When a client needs a resource, it uses the API to communicate with the server. In the server application API documentation, API developers outline how the client should utilize the REST API. The standard procedures for any REST API call are as follows:
- A request is made to the server by the client.
- The client formats the request in accordance with the API documentation so that the server can interpret it.
- The server verifies the client's identity and validates that the client is authorized to submit that request.
- The request is received by the server, which then handles it internally.
- The client receives a response from the server.
- If the request was successful or not is indicated in the response to the client.
- Any information that the client asked for is also included in the response.
- Depending on how the API is designed by the developers, the REST API request and response details differ widely.
The server identifies each resource with unique resource identifiers. For REST services, the server typically performs resource identification by using a Uniform Resource Locator (URL). The URL specifies the path to the resource. A URL is similar to the website address that you enter into your browser to visit any webpage. The URL is also called the request endpoint and clearly specifies to the server what the client requires.
Each resource is assigned a special resource identifier by the server. The server commonly uses a URL to identify resources for REST services. The path to the resource is specified by the URL. The website address you type into your browser to access any webpage is similar to a URL. The URL makes explicit to the server what the client needs and is also known as the request endpoint.
- GET: used to access server-side resources at the URL provided. The server can cache GET requests and include arguments in RESTful API queries.
- POST: used to deliver information to servers. Multiple requests for the same resource result in multiple copies of that resource being created as a byproduct.
- PUT: used to complete update already-existing resources. The same request will not create multiple instances of the resource.
- PATCH: used to modify already-existing resources. In contrast with the PUT, this request changes partial of the resource.
- DELETE: used delete a resource. Usually this returns an empty body.
Additionally, the request includes headers or other metadata. They provide details like the server, encoding, timestamp, and content type and provide further context for the request. Commonly authentication is added as headers.
The resource representation is contained in the request body. Based on the information in the request headers, the server chooses an appropriate representation format. Clients may request data in the Text, XML or JSON formats for example.
- Basic authentication: The user name and password are sent by the client in the request header. Base64 is an encoding method that turns the pair into a collection of 64 characters for secure transmission.
- Bearer authentication: The act of granting access control to the token bearer is referred to as bearer authentication. The server normally generates the bearer token in response to a login request. It is typically an encrypted string of characters. To access resources, the client includes the token in the request headers.
- API keys: Another option for REST API authentication is API keys. In this method, the server gives a brand-new client a special created value. The client uses the special API key to identify itself each time it wants to access resources. Because the client must send the key, which leaves it open to network theft, API keys are less secure.
- OAuth: For extremely secure login access to any system, OAuth combines passwords and tokens. The authorization process is completed by the server after it first requests a password and an extra token. It has a defined scope and longevity and can check the token at any time as well as over time.
The three-digit status code in the status line indicates whether the request was successful or unsuccessful. The first character determines the type of the response, the other digits determine specific type of response.
- 1XX: informational
- 2XX: successful
- 3XX: redirection
- 4XX: client error
- 5XX: server error
The resource representation is contained in the response body. Based on the information in the request headers, the server chooses an appropriate representation format. Clients may request data in the Text, XML or JSON formats for example.
Additionally, the response includes headers or other metadata. They provide details like the server, encoding, timestamp, and content type and provide further context for the response.