In web development, the terms frontend and backend describe different responsibilities within an application. A backend application can provide a REST API through which clients request data and perform operations.
Frontend:
- The frontend provides the user interface, including buttons, forms, and other elements that users interact with.
- It can send requests to the backend and display the data returned in the responses.
- Common web frontend technologies include HTML, CSS, and JavaScript, along with libraries and frameworks such as React, Angular, and Vue.js.
Backend:
- The backend is the part of an application responsible for data management, business logic, and communication with databases.
- It handles tasks such as database operations, authentication, and API endpoints.
- Backend code can be written in languages such as JavaScript, PHP, Python, and Java. This tutorial uses JavaScript with the Node.js runtime and the Express framework. Other frameworks include Django and Spring Boot.
- Databases such as MySQL, PostgreSQL, and MongoDB are often used to store and manage data.
For example, when a user submits a form, the frontend can send an HTTP request to the backend's REST API. The backend validates the input, performs the requested operation, and returns a response that the frontend uses to update the interface.
Full-Stack Development:
A full-stack developer works with both the frontend and backend to build complete applications.
Frontend and backend describe responsibilities, while client-side code and server-side code describe where the code runs. In a web application, client-side code runs in the user's browser and server-side code runs on a server.
A frontend can be implemented as a browser-based application, a mobile app, or a desktop application. Mobile and desktop applications are typically installed on the user's device, where their client-side code runs. In a browser-based application, HTML, CSS, and client-side JavaScript are delivered by a web server to the browser, which displays the interface and runs the client-side JavaScript. The server can also run server-side code to generate HTML before sending it to the browser.
Where code is stored or delivered from does not determine where it runs. For example, a JavaScript file served by a web server can run in the user's browser.
Client-Side Code:
- JavaScript runs in the user's browser to handle interactions and update the page.
- Client-side JavaScript code is delivered to the browser, where users can inspect it.
Security note: Client-side code is delivered to the user's browser, where users can inspect and modify it. Never include secrets such as private API keys, database credentials, or signing keys in client-side code. Authentication checks, authorization decisions, and validation that protects data must be enforced on the server. Client-side validation can improve the user experience, but the server must independently validate incoming requests.
Server-Side Code:
- Code runs on the server to process requests, apply business rules, and access data.
- Examples include PHP, Python, Java, and JavaScript running in Node.js.
- The server sends a response to the client, such as generated HTML for a web page or JSON data for an API request.
- Server-side source code is normally not sent to the client in the HTTP response.
JavaScript can be used for both client-side code and server-side code. Client-side JavaScript runs in the user's browser, for example to handle user interactions and update the page. Server-side JavaScript runs on a server using a runtime such as Node.js, for example to process requests and access data. A single application can use JavaScript on both the client and the server.
REST is acronym for REpresentational State Transfer. REST API is an application which communicates with the clients using HTTP-protocol. The client can be a web-application, or Mobile application or any application which is able to use HTTP. The REST API will handle the connection to the database.
The main HTTP methods used in REST APIs are:
- GET - Retrieve/read data from the server
- POST - Create new resources
- PUT - Replace/update an entire resource
- PATCH - Partially update a resource
- DELETE - Remove a resource
Example REST API Structure:
For a user management system, typical endpoints might look like:
GET /api/users- Get all usersGET /api/users/:id- Get a specific user by IDPOST /api/users- Create a new userPUT /api/users/:id- Update an entire user recordPATCH /api/users/:id- Update specific fields of a userDELETE /api/users/:id- Delete a user
You can create the REST API using various languages such as Java, PHP, Node.js, Python, etc. This tutorial uses Node.js with the Express framework.
REST allows different messaging formats, such as HTML, JSON, and XML. This tutorial is focused on JSON (JavaScript Object Notation).
REST API uses HTTP requests to GET, PUT, POST and DELETE data.
You can read more about it from:
Within computer programming, the acronym CRUD stands for create, read, update and delete. The acronym CRUD refers to the major operations which are implemented by databases. Each letter in the acronym can be mapped to a standard Structured Query Language (SQL) statement and HTTP method used in REST APIs.
| CRUD Operation | SQL Statement | HTTP Method | REST API Example |
|---|---|---|---|
| Create | INSERT | POST | POST /api/users |
| Read | SELECT | GET | GET /api/users or GET /api/users/5 |
| Update | UPDATE | PUT / PATCH | PUT /api/users/5 or PATCH /api/users/5 |
| Delete | DELETE | DELETE | DELETE /api/users/5 |
Note: This mapping shows how database operations (CRUD) are exposed through a REST API using HTTP methods. When a client sends an HTTP request (e.g., POST /api/users), the REST API server translates this into the corresponding SQL operation (INSERT) to interact with the database.
HTTP(Hypertext Transfer Protocol) is a protocol which is used to transfer files over the ip-network. You can read more about http from https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview.
HTTP message is the data that is exchanged between a server and a client. There are two types of messages:
- requests: sent by the client to trigger an action on the server
- responses: the answer from the server to the client
Http message includes always headers and it can also include a body.
In REST API we can use these HTTP methods:
- POST (to add data)
- GET (to show data)
- PUT (to update data)
- PATCH (to partially update data)
- DELETE (to remove data)
When you are using GET and DELETE you can add data only inside the URL or headers. When you are using POST, PUT and PATCH you can add data to both headers and body.
Example if you want to send a variable named fname, with a value Jim using GET-method, then the url will be something like
http://localhost/api/?fname=Jim
But if you are using POST-method then, the url is just like this
http://localhost/api
When we are using DELETE, we will add the id to the url on the same way as in GET-method. And when we are using PUT or PATCH, we will add the id to the url and the update data to the body.
A common practice when building a REST API is that you don't need to include variable names as query parameters in your GET requests. So that instead of this kind of url
http://localhost/api/?id=5
You can use a cleaner, more RESTful URL like:http://localhost/api/5
Both PUT and PATCH methods are used to update existing resources, but they have different semantic meanings:
PUT is typically used for full resource update. When you send a PUT request, you should send the complete representation of the resource. If you omit some fields, they might be set to null or default values.
PATCH is used for partial resource update. When you send a PATCH request, you only need to send the fields that you want to modify. The other fields remain unchanged.
Example:
Let's say you have a user resource with fields: name, email, phone, and address.
- With PUT, if you want to update only the email, you typically need to send all fields: name, email, phone, and address.
- With PATCH, you can send only the email field, and the other fields remain unchanged.
Important note: However, the actual behavior depends on how the developer implements the backend code. The HTTP method itself doesn't enforce these rules - it's the SQL code and business logic written by the developer that determines whether the update is full or partial. A developer could implement PUT to do partial updates or PATCH to do full updates, but this would go against REST conventions and best practices.
You can read more about those methods from:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
http://www.restapitutorial.com/lessons/httpmethods.html
The http response includes status code, which gives information about the response. The most important classes of the codes are:
- 200 - 299 : Success
- 400 - 499 : Client errors
- 500 - 599 : Server error
You can read about the status codes from:
https://www.restapitutorial.com/httpstatuscodes.html
HTTPS(Hypertext Transfer Protocol Secure) is an extension for the HTTP. If you use HTTP, all the information will be transfered in plain text format. But if you use HTTPS, the information will be encrypted.
JSON objects are written inside curly brackets. Example like this
{
"id_book": 11,
"name": "javascript",
"author": "Mike Jones",
"isbn": "9780030604577"
}
JSON arrays are written inside square brackets. The array can contain several objects. Like this
[
{
"id_book": 11,
"name": "New Book",
"author": "Mike",
"isbn": "22"
},
{
"id_book": 7,
"name": "Signal Slot",
"author": "Jim Bim",
"isbn": "2345-66"
}
]
CORS allows web applications from one domain to access resources from another domain. Without CORS, browsers restrict cross-origin HTTP requests initiated by scripts, which could prevent your API from being accessed by clients running on different domains.
First, install the cors middleware:
npm install cors
To allow requests from all domains, use cors() without any options:
const cors = require('cors');
app.use(cors());
To allow requests only from https://mydomain.com, set the origin option:
const cors = require('cors');
app.use(cors({
origin: 'https://mydomain.com'
}));
Authentication and authorization are two vital information security processes that administrators use to protect systems and information. Authentication verifies the identity of a user or service, and authorization determines their access rights.
Authorization is the security process that determines a user or service's level of access. In technology, we use authorization to give users or services permission to access some data or perform a particular action.
The purpose of authentication is to verify that someone or something is who or what they claim to be.
Other commonly used approaches include HTTP Basic authentication and OAuth 2.0 combined with OpenID Connect. This guide focuses on authentication using JSON Web Tokens (JWT).
JWTs or JSON Web Tokens are most commonly used to identify an authenticated user. JWT authentication follows a 4 step process:
- Client sends credentials: Client sends POST request with username and password to auth server.
- Server validates and generates token: Server checks the credentials against the database. If valid, server generates a JWT token and sends it to the client. The server does not store the token - the client saves it (typically in localStorage or sessionStorage).
- Client sends authenticated request: For every subsequent request, the client sends the JWT in the Authorization header (Bearer scheme). Server validates the token using the secret key.
- Server responds with data: Once the token is validated, server sends the requested data to the client.
JWT Authentication Process
When sending an authenticated request, the JWT token is included in the Authorization header using the Bearer scheme:
Authorization: Bearer <token>
JWT Token Structure:
A JWT token consists of three parts separated by dots (.):
{
"alg": "HS256",
"typ": "JWT"
}
{
"userId": 123,
"name": "John Doe",
"iat": 1616239022
}
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )
- Not encrypted: The Header and Payload are only Base64-encoded, not encrypted. Anyone can decode and read them.
- Don't store sensitive data: Never put passwords, credit card numbers, or other sensitive information in the token payload.
- Signature provides integrity: The signature ensures the token hasn't been tampered with, but doesn't hide the content.
- Use HTTPS: Always transmit JWT tokens over HTTPS to prevent interception.
Example of sending JWT token in JavaScript:
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'; fetch('/api/users/profile', { method: 'GET', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${token}` } }) .then(response => response.json()) .then(data => console.log(data));