MINISTRY OF INFORMATION AND COMMUNICATIONS

POSTS AND TELECOMMUNICATIONS INSTITUTE OF

TECHNOLOGY

SUBJECT: SOFTWARE ARCHITECTURE & DESIGN

Assignment: ASSIGNMENT 2: E-COMMERCE - REST API-

VP TOOL

Class : E21CNPM02
Students : Bùi Nguyễn Tùng Lâm

​
​

Hanoi, 17/03/2025 ​
Question 1

What is REST?

REpresentational State Transfer

REST, or REpresentational State Transfer, is an architectural style for providing
standards between computer systems on the web, making it easier for systems to
communicate with each other. REST-compliant systems, often called RESTful systems,
are characterized by how they are stateless and separate the concerns of client and
server. We will go into what these terms mean and why they are beneficial
characteristics for services on the Web.

Separation of Client and Server

In the REST architectural style, the implementation of the client and the
implementation of the server can be done independently without each knowing about
the other. This means that the code on the client side can be changed at any time
without affecting the operation of the server, and the code on the server side can be
changed without affecting the operation of the client.

As long as each side knows what format of messages to send to the other, they can be
kept modular and separate. Separating the user interface concerns from the data
storage concerns, we improve the flexibility of the interface across platforms and
improve scalability by simplifying the server components. Additionally, the separation
allows each component the ability to evolve independently.
By using a REST interface, different clients hit the same REST endpoints, perform the
same actions, and receive the same responses.

Statelessness
Systems that follow the REST paradigm are stateless, meaning that the server does not
need to know anything about what state the client is in and vice versa. In this way, both
the server and the client can understand any message received, even without seeing
previous messages. This constraint of statelessness is enforced through the use of
resources, rather than commands. Resources are the nouns of the Web - they describe
any object, document, or thing that you may need to store or send to other services.

Because REST systems interact through standard operations on resources, they do not
rely on the implementation of interfaces.

These constraints help RESTful applications achieve reliability, quick performance, and
scalability, as components that can be managed, updated, and reused without affecting
the system as a whole, even during operation of the system.

Communication between Client and Server

In the REST architecture, clients send requests to retrieve or modify resources, and
servers send responses to these requests. Let’s take a look at the standard ways to make
requests and send responses.

Making Requests
REST requires that a client make a request to the server in order to retrieve or modify
data on the server. A request generally consists of:

●​ an HTTP verb, which defines what kind of operation to perform

●​ a header, which allows the client to pass along information about the request
●​ a path to a resource
●​ an optional message body containing data

HTTP Verbs
There are 4 basic HTTP verbs we use in requests to interact with resources in a REST
system:

●​ GET — retrieve a specific resource (by id) or a collection of resources

●​ POST — create a new resource
●​ PUT — update a specific resource (by id)
●​ DELETE — remove a specific resource by id

Headers and Accept parameters

In the header of the request, the client sends the type of content that it is able to
receive from the server. This is called the Accept field, and it ensures that the server
does not send data that cannot be understood or processed by the client. The options
for types of content are MIME Types (or Multipurpose Internet Mail Extensions), which
you can read more about in the MDN Web Docs.

MIME Types, used to specify the content types in the Accept field, consist of a type and
a subtype. They are separated by a slash (/).

For example, a text file containing HTML would be specified with the type text/html. If
this text file contained CSS instead, it would be specified as text/css. A generic text file
would be denoted as text/plain. This default value, text/plain, is not a catch-all,
however. If a client is expecting text/css and receives text/plain, it will not be able to
recognize the content.

Paths
Requests must contain a path to a resource that the operation should be performed on.
In RESTful APIs, paths should be designed to help the client know what is going on.

Conventionally, the first part of the path should be the plural form of the resource. This
keeps nested paths simple to read and easy to understand.

A path like [Link]/customers/223/orders/12 is clear in what it points to,

even if you’ve never seen this specific path before, because it is hierarchical and
descriptive. We can see that we are accessing the order with id 12 for the customer with
id 223.

Paths should contain the information necessary to locate a resource with the degree of
specificity needed. When referring to a list or collection of resources, it is not always
necessary to add an id. For example, a POST request to the
[Link]/customers path would not need an extra identifier, as the server
will generate an id for the new object.

If we are trying to access a single resource, we would need to append an id to the path.
For example: GET [Link]/customers/:id — retrieves the item in the
customers resource with the id specified. DELETE [Link]/customers/:id —
deletes the item in the customers resource with the id specified.

Sending Responses

Content Types
In cases where the server is sending a data payload to the client, the server must
include a content-type in the header of the response. This content-type header field
alerts the client to the type of data it is sending in the response body. These content
types are MIME Types, just as they are in the accept field of the request header. The
content-type that the server sends back in the response should be one of the options
that the client specified in the accept field of the request.

For example, when a client is accessing a resource with id 23 in an articles resource with
this GET Request:

GET /articles/23 HTTP/1.1

Accept: text/html, application/xhtml

The server might send back the content with the response header:

HTTP/1.1 200 (OK)

Content-Type: text/html

This would signify that the content requested is being returned in the response body
with a content-type of text/html, which the client said it would be able to accept.

Response Codes
Responses from the server contain status codes to alert the client to information about
the success of the operation. As a developer, you do not need to know every status code
(there are many of them), but you should know the most common ones and how they
are used:

Status code Meaning

This is the standard response for successful

200 (OK)
HTTP requests.

This is the standard response for an HTTP

201 (CREATED) request that resulted in an item being
successfully created.

This is the standard response for successful

204 (NO
HTTP requests, where nothing is being returned
CONTENT)
in the response body.
 The request cannot be processed because of bad
400 (BAD
request syntax, excessive size, or another
REQUEST)
client error.

The client does not have permission to access

403 (FORBIDDEN)
this resource.

The resource could not be found at this time. It

404 (NOT FOUND) is possible it was deleted, or does not exist
yet.

500 (INTERNAL The generic answer for an unexpected failure if

SERVER ERROR) there is no more specific information available.

For each HTTP verb, there are expected status codes a server should return upon
success:

●​ GET — return 200 (OK)

●​ POST — return 201 (CREATED)
●​ PUT — return 200 (OK)
●​ DELETE — return 204 (NO CONTENT) If the operation fails, return the most
specific status code possible corresponding to the problem that was
encountered.

Why do we need to use REST?

REST (Representational State Transfer) is a set of architectural principles used in
designing networked applications, particularly for web services. Here’s why we use
REST:

1.​ Statelessness: Each request from a client to a server must contain all the
information needed to understand and process the request. This reduces server
overhead and makes the system more scalable.
2.​ Scalability: Because REST services are stateless, they can handle a large number
of requests. Each request is independent, allowing for load balancing and
horizontal scaling of the system.
3.​ Simplicity: REST APIs use standard HTTP methods (GET, POST, PUT, DELETE) to
interact with resources. This makes them easy to understand, implement, and
maintain.
 4.​ Interoperability: REST is based on HTTP, which is widely supported across
different platforms and programming languages. This allows different systems to
communicate with each other effectively.
5.​ Caching: Responses from REST APIs can be explicitly marked as cacheable or
non-cacheable, improving performance by reducing the need to repeatedly
process the same requests.
6.​ Flexibility: RESTful services can support different formats, including JSON, XML,
and others, giving clients the flexibility to choose their preferred data
representation.
7.​ Separation of concerns: REST encourages a clear separation between client and
server, allowing each to evolve independently. This means clients don’t need to
know how the server implements the service, and servers don't need to know the
client’s implementation.
8.​ Widely adopted: REST has become the standard for web APIs, meaning there are
many resources, libraries, and tools available for building and interacting with
RESTful services.

In summary, REST is widely used because it is simple, scalable, flexible, and allows
different systems to interact seamlessly using standard HTTP methods.

Steps for building REST in Django

Building a RESTful API in Django typically involves using the Django Rest Framework
(DRF), which simplifies the process of creating APIs. Below are the steps to build a REST
API in Django:

1. Set Up Django Project

If you don’t already have a Django project, start by creating one.

2. Install Django Rest Framework (DRF)

To create RESTful APIs, you need to install the Django Rest Framework package.
3. Add DRF to Installed Apps

In your [Link] file, add 'rest_framework' to the INSTALLED_APPS list.

4. Create a Django App

Now, create a Django app where you will build your API.

5. Define Your Models

In your app’s [Link], define the models that will represent your database tables.
Here’s an example:

6. Create Serializers
Serializers convert complex data types like Django models into JSON or XML formats. In
your app, create a [Link] file and define a serializer for your model:

7. Create Views

Now, create views for your API. DRF provides several classes for creating views, such as
APIView or viewsets like ModelViewSet. Here’s an example of creating a simple view
using APIView:

In your [Link] file:

8. Set Up URLs
Next, set up URLs to route the requests to the views. Create a [Link] file in your app
and add routes for your API views:

Also, include these URLs in your project's main [Link]:

9. Run Migrations

After defining the models, you need to apply migrations to create the necessary
database tables.

10. Test the API

Now you can run your Django development server and test the API endpoints.
Test your API in the browser or using a tool like Postman:

●​ GET request to [Link] should return a list of

items.
●​ POST request to [Link] should allow you to
add a new item.

What is serialize? Why we need it?

What is Serialization?

Serialization is the process of converting complex data types, such as Django model
instances or Python objects, into a format that can be easily rendered into a format like
JSON, XML, or other content types. In the context of web development, serialization is
crucial because it allows you to send data between a client and a server in a readable
and transferable format.

In Django, serialization is commonly used with Django Rest Framework (DRF) to

convert model instances into JSON (or other formats) so that they can be returned in
API responses. This process is achieved through serializers.

Why Do We Need Serialization?

Serialization is important in web applications and APIs for several reasons:

1.​ Converting Data to JSON (or other formats):

○​ Web clients (browsers, mobile apps, etc.) communicate with servers
through HTTP, typically sending and receiving data in formats like JSON
or XML. However, data in databases (Django models, for instance) is often
in Python objects or instances that need to be converted into a format
suitable for HTTP communication (usually JSON).
○​ Serialization allows you to easily convert complex Django models (or
Python objects) into JSON or other formats, which are then sent over
HTTP responses.
2.​ Data Transmission Between Client and Server:
○​ Serialization makes it possible to send structured data over the internet
between the server (which holds the data) and the client (which consumes
the data). Since most web applications work over HTTP, data needs to be
transferred in a format that both the server and client can understand
and process.
○​ The server typically sends serialized data in the form of JSON or XML,
while the client (for instance, a web browser or mobile app) can then
parse this data and use it.
 3.​ Maintaining Data Integrity and Structure:
○​ Serialization ensures that the data is transferred correctly and
consistently between the client and the server. It also ensures that any
complex objects, relationships, or nested data are correctly represented
and preserved.
○​ For example, if you have a Django model with related fields (ForeignKey,
ManyToMany, etc.), serializers can handle these relationships and ensure
that they are represented correctly in the output (e.g., nested JSON
structures).
4.​ Validation:
○​ Serialization often includes validation rules, which can be used to ensure
that incoming data is correct before saving it to the database. This is
especially useful for APIs where data is received from external clients.
○​ A serializer can validate data, ensuring that it adheres to the expected
format or constraints, and can raise errors if the data is invalid.
5.​ Simplifying the Code:
○​ Instead of manually converting model data to dictionaries or JSON,
serializers in Django Rest Framework (DRF) provide a simple and efficient
way to automatically convert and validate complex data types.
○​ DRF serializers automatically handle the conversion of complex objects to
and from Python dictionaries and JSON, reducing the amount of
boilerplate code you need to write.
6.​ REST API Best Practices:
○​ In REST APIs, it’s a common pattern to convert data into a format that can
be easily consumed by the client. Serialization ensures that your data is
structured and organized in a way that adheres to REST principles.
○​ It allows the API to send consistent, readable data structures, such as
JSON objects, to the client.

Ecommerce_API
Customer_API
Book_API

Question 2

Use case diagrams

Customer Module
Item Module
Cart Module
Order module
Shipping Module
Payment Module
Class Diagram

REST_API

Authentication

[Link]

[Link]
[Link]

[Link]

Customer
[Link]
[Link]

[Link]
[Link]

Item
[Link]

[Link]
[Link]

[Link]

Cart
[Link]
[Link]

[Link]

[Link]
Order
[Link]

[Link]

[Link]

[Link]
Payment
[Link]

[Link]

[Link]
[Link]

Shipping
[Link]

[Link]

[Link]
[Link]