build-a-restful-api-with-laravel-400x277.png

This course will begin our journey into Application Programming Interface(API) Development with Laravel.  In this course, we will be going over topics like:
- Concept of Application Programming Interface (API)  and its benefits, 
- Representational State Transfer (REST) Architecture and its constraints, 
- JSON Web Token (JWT) for authentication, 
- best practices for designing a RESTful API, and much more.

We will be putting this knowledge into practical use by building a Question & Answer Restful API Application.

Application Features

- Users can signup and sign in.
- Users can reset their passwords.
- Authenticated users can post a question.
- Authenticated users can answer a question.
- The question owner can delete his question.
- Answer owner can delete his answer.

This course requires an understanding of PHP and a basic understanding of the Laravel framework. 

By the end of this course, we will be able to begin our journey in creating RESTful APIs in Laravel.

Building a Question & Answer RESTful API Application

## Introduction

> REST refers to a group of software architecture design constraints that bring about efficient, reliable, and scalable distributed systems. 
-- <cite>MDN Web Docs</cite>

REST is not a technology but a structure or design methodology that produces standardized and consistent behavior or output. This output can be either JSON or XML. REST API uses HTTP requests to access and use data. The basic idea of REST is that a resource (document, media, data) is transferred via well-recognized, language-agnostic, and standardized client-server interactions.

## REST architecture constraints

The REST architectural style describes six guiding constraints:
  
1. **Uniform Interface:** The uniform interface constraint defines that the server must have a uniform way of interacting with the client irrespective of the client type. The four principles of the uniform interface constraint are:

     - **Resource identification in requests:** Within API requests, we can identify individual resources. That is, a URI must specify the resource it wants.

     - **Resource manipulation through representations:** When a client has the representation of a resource, it should contain enough information to delete or modify the resource provided it has permission to do so.

     - **Self-descriptive messages:** Each resource representation should carry enough information to describe how to process the message.

     - **Hypermedia as the engine of application State:** The client can use server-provided links to discover the available resources it needs dynamically.

2. **Client-Server Architecture:** This constraint ensures the separation of concerns. The client manages user interface concerns while the server manages data storage concerns.

3. **Statelessness:**  The server should store no client context or information (state) between requests. The client is responsible for keeping its session state, and all requests sent from the client must be self-contained and complete. If the server needs to store the state, it must pass it to a database or similar service to persist the data.

4. **Cacheability:**  The server must mark REST responses as cacheable or not. It is to ensure caching works as expected on the client end. This constraint prevents clients from reusing stale or inappropriate data in response to further requests. 

5. **Layered System:** The client cannot tell if it's connected to the server or an intermediary like a CDN (Content Delivery Network).

6. **Code on demand:**  This is an optional constraint. Servers can transfer executable codes like Javascript to clients to extend and customize and functionalities.

RESTful APIs are APIs that adhere to the REST constraints. 

## Anatomy of a REST request

A REST request consists mainly of 4 parts:
- URI (commonly called endpoint)
- HTTP Method
- Headers
- Body

The **method** is one of the standard HTTP methods, and the **URI** points to the location of the resource. These two parts make up a basic REST request. The client can send metadata along with the request as part of the **header**. If we want to send data to the REST API, we must pass it in the **body**. 



# Introduction

> REST refers to a group of software architecture design constraints that bring about efficient, reliable, and scalable distributed systems. 
-- <cite>MDN Web Docs</cite>

REST is not a technology but a structure or design methodology that produces standardized and consistent behavior or output. This output can be either JSON or XML. REST API uses HTTP requests to access and use data. The basic idea of REST is that a resource (document, media, data) is transferred via well-recognized, language-agnostic, and standardized client-server interactions.

# REST architecture constraints

The REST architectural style describes six guiding constraints:
  
1. **Uniform Interface:** The uniform interface constraint defines that the server must have a uniform way of interacting with the client irrespective of the client type. The four principles of the uniform interface constraint are:

     - **Resource identification in requests:** Within API requests, we can identify individual resources. That is, a URI must specify the resource it wants.

     - **Resource manipulation through representations:** When a client has the representation of a resource, it should contain enough information to delete or modify the resource provided it has permission to do so.

     - **Self-descriptive messages:** Each resource representation should carry enough information to describe how to process the message.

     - **Hypermedia as the engine of application State:** The client can use server-provided links to discover the available resources it needs dynamically.

2. **Client-Server Architecture:** This constraint ensures the separation of concerns. The client manages user interface concerns while the server manages data storage concerns.

3. **Statelessness:**  The server should store no client context or information (state) between requests. The client is responsible for keeping its session state, and all requests sent from the client must be self-contained and complete. If the server needs to store the state, it must pass it to a database or similar service to persist the data.

4. **Cacheability:**  The server must mark REST responses as cacheable or not. It is to ensure caching works as expected on the client end. This constraint prevents clients from reusing stale or inappropriate data in response to further requests. 

5. **Layered System:** The client cannot tell if it's connected to the server or an intermediary like a CDN (Content Delivery Network).

6. **Code on demand:**  This is an optional constraint. Servers can transfer executable codes like Javascript to clients to extend and customize and functionalities.

RESTful APIs are APIs that adhere to the REST constraints. 

# Anatomy of a REST request

A REST request consists mainly of 4 parts:
- URI (commonly called endpoint)
- HTTP Method
- Headers
- Body

The **method** is one of the standard HTTP methods, and the **URI** points to the location of the resource. These two parts make up a basic REST request. The client can send metadata along with the request as part of the **header**. If we want to send data to the REST API, we must pass it in the **body**. 



Learn about the Representation State Transfer (REST) architecture and its constraints by analyzing a RESTful request.

Getting Started

Introduction to API Assessment

Quick Refresher

Authentication

Create Question Endpoints

Create Answer Endpoints

Tags

Database Seeding

Password Reset

Conclusion

What Is a RESTful API?

Introduction

REST architecture constraints