Scribd
Upload
6 views

490+19.+REST+API

The document provides an overview of RESTful APIs, explaining their definition, architectural constraints, and best practices for structuring applications using Express. It details six primary design principles of REST, including statelessness and client-server decoupling, and outlines general best practices for file structure in Node.js projects. Additionally, it presents examples of file hierarchies for websites and RESTful APIs, emphasizing the importance of organization for maintainability.

Uploaded by

Morsal AL-hugafi
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
6 views

490+19.+REST+API

The document provides an overview of RESTful APIs, explaining their definition, architectural constraints, and best practices for structuring applications using Express. It details six primary design principles of REST, including statelessness and client-server decoupling, and outlines general best practices for file structure in Node.js projects. Additionally, it presents examples of file hierarchies for websites and RESTful APIs, emphasizing the importance of organization for maintainability.

Uploaded by

Morsal AL-hugafi
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

Technology

Primer –
RESTful APIs
LECTURE 19
RESTful APIs
REST API (aka RESTful API)
◦ An application programming interface (API) that conforms to constraints of REST architectural style and
allows for interaction with RESTful web services.

API
◦ A set of rules that define how applications or devices can connect to and communicate with each other.

REST (Representational State Transfer)


◦ An architectural style defined in 2000 by computer scientist Dr. Roy Fielding in his doctoral dissertation.
REST provides a relatively high level of flexibility as there are six (6) primary design principles, known as
architectural constraints.
REST Architectural Constraints
1. Uniform interface
a. All API requests for the same resource should look the same, no matter where the request comes
from.
b. The REST API should ensure that the same piece of data, such as the name or email address of a
user, belongs to only one uniform resource identifier (URI).
2. Client-server decoupling
a. In REST API design, client and server applications must be completely independent of each other.
b. The only information the client application should know is the URI of the requested resource; it can’t
interact with the server application in any other ways. Similarly, a server application shouldn’t modify
the client application other than passing it to the requested data via HTTP.
3. Statelessness
a. REST APIs are stateless, meaning that each request needs to include all the information necessary for
processing it.
b. In other words, REST APIs do not require any server-side sessions. Server applications aren’t allowed
to store any data related to a client request.
REST Architectural Constraints cont.
4. Cacheability
◦ When possible, resources should be cacheable on the client or server side.
◦ Server responses also need to contain information about whether caching is allowed for the delivered
resource. The goal is to improve performance on the client side, while increasing scalability on the server
side.
5. Layered system architecture
◦ In REST APIs, the calls and responses go through different layers. As a rule of thumb, don’t assume that
the client and server applications connect directly to each other.
◦ There may be a number of different intermediaries in the communication loop. REST APIs need to be
designed so that neither the client nor the server can tell whether it communicates with the end
application or an intermediary.
6. Code on demand (optional)
◦ REST APIs usually send static resources, but in certain cases, responses can also contain executable code
(such as Java applets).
◦ In these cases, the code should only run on-demand.
How are APIs used?
Create mobile applications

Create single page applications

Use AJAX calls

Provide data to clients

Etc.

RESTful APIs and methods provide us with almost all the information we need to process a
request.
Best Practices – File Structure
Express does not follow a defined structure.

You can technically structure the application however you want.

However, as the application grows in size, it will become very difficult to maintain if it doesn’t have
a well-defined structure.

The next several slides have some widely adopted “best practices” for how to structure your
Express application.
General Best Practices
● Always begin a node project with npm init

● Stick with lowercase file names and camelCase variables


◦ If you look at any npm module, its named in lowercase and separated with dashes. Whenever you require
these modules, use camelCase.

● Do not push node_modules to your repositories.


◦ This means add **/node_modules to your .gitignore files.

● Use a config to store variables

● Group and isolate routes to their own file.


File Hierarchy - Websites
mysite ● db.js contains the database connection and config
◦ index.js
● credentials.js Password/API keys
◦ routes.js
◦ package.json ● config.js Other environment variables
◦ node_modules
◦ config
● models folder contains mongoose schemas
◦ db.js
● routes folder contains the different sub-routes
◦ credentials.js
◦ config.js ● public folder contains all of the static content
◦ models
◦ users.js ● top-level routes.js file requires all sub-routes within this file
◦ routes
◦ users.js
◦ views
◦ index.pug
File Hierarchy – RESTful APIs
mysite APIs are similar but do not need a public or
◦ index.js views directory.
◦ routes.js
Model View Controller (MVC) Design:
◦ package.json
◦ Those familiar with the Model View Controller
◦ node_modules (MVC) architectural pattern may notice the
◦ config inclusion of a controllers folder which is used
◦ db.js to separate out the control logic from the
◦ credentials.js “routes”.
◦ models
◦ users.js
◦ routes
◦ users.js
◦ controllers
◦ users.js
Candy Land Example Structure
candy-land
◦ index.js
◦ routes.js
◦ package.json
◦ node_modules
◦ config
◦ db.js
◦ models
◦ candy.js
◦ routes
◦ candy.js
◦ controllers
◦ candy.js
Candy Land – DB Connection
Candy Land – Model Schema 1
Candy Land – Model Schema 2
RESTful Naming Convention
Candy Land – High Level Routes
Note: this is just an aggregator of all other routes.
Candy Land - Routes
Candy Land – Controller (1 of 8)
Candy Land – Controller (2 of 8)
Candy Land – Controller (3 of 8)
Candy Land – Controller (4 of 8)
Candy Land – Controller (5 of 8)
Candy Land – Controller (6 of 8)
Candy Land – Controller (7 of 8)
Candy Land – Controller (8 of 8)
Candy Land – index (1 of 2)
Candy Land – index (2 of 2)

You might also like