Đồ Án Cuối Kỳ Môn Học Các Nền Tảng Phát Triển Phần Mềm Chủ Đề Web Api.pdf

HTTP Method Phương thức HTTP: Yêu cầu này thường được gửi bằng các phương thức HTTP như GET, POST, PUT, DELETE để chỉ định hành động cụ thể mà người dùng muốn thực hi n v i resource.. Xử

TRƯỜNG ĐẠI HỌC VĂN LANGKHOA CÔNG NGHỆ THÔNG TIN

ĐỒ ÁN CUỐI KỲ MÔN HỌC CÁC NỀN TẢNG PHÁT TRIỂN PHẦN MỀM

Chủ đề:

Web API

SVTH: 2274802010899_Nguyễn Thanh

Tính LỚP: 232_71ITDS30103_03

TP Hồ Chí Minh – 4/2024

2 M c L c ụụ

CHƯƠNG 1: GIỚI THIỆU WEB API 3

CHƯƠNG 2: KHÁI NIỆM VỀ WEB API 4

I/ T ng quan v Restful API ổ ề 4

1 Các dạng Request c a Restful API ủ 4

2 Nguyên tắc thiết k Restful ế 4

CHƯƠNG 3: QUI TRÌNH HOẠT ĐỘNG 5

CHƯƠNG 4: MINH HỌA/ DEMO 11

CHƯƠNG CUỐI: KẾT LUẬN VÀ ĐỀ XUẤT 15

3

CHƯƠNG 1: GIỚI THIỆU WEB API

RESTful API là một tiêu chuẩn được sử dụng trong việc thiết kế API cho các phần mềm, ứng dụng và dịch vụ web để tạo sự thuận tiện cho việc quản lý các resource Các tài nguyên hệ thống như tệp văn bản, ảnh, video, âm thanh hay dữ liệu di động là mục tiêu mà nó hướng tới, bao gồm các trạng thái tài nguyên được định dạng và truyền tải qua HTTP

Hay có thể nói theo cách khác, nó sẽ là 1 cây cầy để bắc qua nếu các trang web thống nhất với nhau về việc trả lại dữ liệu tương ứng Nhưng mà trăm nghe không bằng mắt thấy nên ở bài viết này mình sẽ không đi sâu về mặt lý thuyết, chỉ nêu tổng quát cách hoạt động của RESTful => từ đó đưa ra demo để có thể quan sát tốt hơn

4

CHƯƠNG 2: KHÁI NIỆM VỀ WEB API

I/ T ng quan v Restful API ổề1 Các dạng Request c a Restful API ủ

Http Method gồm có 9 loại nhưng RESTful chỉ sử dụng 4 loại phổ biến

• GET (SELECT): Tr v m t Resource ho c mả ề ộ ặ ột danh sách Resource

• POST (CREATE): T o m i m t Resource ạ ớ ộ

• PUT (UPDATE): C p nhậ ật thông tin cho Resource

• DELETE (DELETE): Xoá một Resource

Tương ứng với cái tên thường gọi là CRUD (Create, Read, Update, Delete)

2 Nguyên tắc thiết k Restful ế

Khi chúng ta gửi 1 request tới 1 API nào đó thì sẽ có vài status code để nhận biết như sau:

• 200 OK – Trả ề v thành công cho tất cả phương thức

• 201 Created – Trả ề v khi một Resource đượ ạo thành công.c t

• 204 No Content – Trả ề v khi Resource xoá thành công

• 304 Not Modified – Client có thể sử dụng dữ liệu cache

• 400 Bad Request – Request không hợp lệ

• 401 Unauthorized Request c– ần có auth

• 403 Forbidden b t – ị ừ chối không cho phép

• 404 Not Found – Không tìm thấy resource từ URI

• 405 Method Not Allowed – Phương thức không cho phép với user hiện tại

• 410 Gone – Resource không còn tồ ại, Version cũ đã không còn hỗn t trợ

• 415 Unsupported Media Type – Không hỗ trợ kiểu Resource này

• 422 Unprocessable Entity D – ữ liệu không được xác thực

• 429 Too Many Requests Request b t – ị ừ chối do b ị giớ ạn i h

• API được thiết k ế phải rõ ràng, nhìn vào phải biết được API th c hiự ện cái gì

5

CHƯƠNG 3: QUI TRÌNH HOẠT ĐỘNG 3.1 Qui trình

a Yêu cầu (Request)

Endpoint (Điểm kết thúc): Người dùng hoặc ứng d ng gụ ửi yêu cầu đến một endpoint c ụ thể trên máy chủ

HTTP Method (Phương thức HTTP): Yêu cầu này thường được gửi bằng các phương thức HTTP như GET, POST, PUT, DELETE để chỉ định hành động cụ thể mà người dùng muốn thực hi n v i resource ệ ớ

Xử lý yêu cầu Kiểm tra xác thực và ủy quyền: Máy chủ ểm tra thông tin xác thự ki c của người dùng và ủy quyền quyền truy cập

Xử lý Logic: Máy chủ x ử lý logic yêu cầu dựa trên phương thức và endpoint được ch nh ỉ đị

Truy v n CSDL (n u c n): Nấ ế ầ ếu yêu cầu liên quan đến dữ liệ ừ cơ sở ữu t d liệu, máy chủ sẽ thực hiện truy vấn và trả về kết quả

Header: Máy chủ trả về các header để cung cấp thông tin bổ sung, ví dụnhư thời gian ph n h i, lo i d ả ồ ạ ữ liệu, v.v

c Xử lý lỗi (nếu có)

Nếu có lỗi xảy ra trong quá trình xử lý yêu cầu, máy chủ s v ẽ trả ề mã trạng thái HTTP phù hợp và thông điệ ỗi để thông báo cho người dùng hoặp l c ứng d ng về lỗi đó ụ

6

d Đóng kết nối (nếu có)

Máy chủ có thể đóng kết nối nếu yêu cầu hoàn thành hoặc duy trì kết nối cho các yêu cầu tiếp theo nếu người dùng hoặc ứng dụng muốn duy trì phiên làm việc

3.2 Chức năng:

Phầ ạn t o API

• Thực hi n trả về là HttpResponseMessage để xác định ệđược StatusCode v trả ề là bao nhiêu (thực hi n tr v ệ ả ề StatusCode như

phần Nguyên tắc thiết kế RESTful mà mình đã đề cập ở phần 2)

• Hoặc có thể trả về kèm với Jsonbáo lỗi bên trong Content ủ HttpClient c a

2.1 GET METHOD

• PHẦN USERCONTROLER

o Thêm đoạn code th c hiự ện phương thức GET để lấy t t cấ ả User

• Uri c a website sủ ẽ là phầ host:port + /api/{tên controller}/{action của n controller}/{tham s nố ếu có} như phần cấu hình ở file Config

• Khi truy cập vào địa ch ỉ/api/User/GetAllUser chúng ta sẽ thu được 5 User đã tạo dưới dạng Json

7 POST METHOD

Ở các phần Post, Put và Delete về sau sẽ phải dùng 1 công cụ hỗ trợ để gửi request mới có thể xác định được dữ liệu thu được là gì, vì request gửi đi sẽ ở dạng gửi ngầm không thể nhìn thấy

• Ở đây sẽ s dử ụngPOSTMAN test th , hoử ặc có thể vào https://reqbin.com/ đểtrực ti p s dụng trên web không cần tải về ế ử

• Lưu ý: Nh m b o mằ ả ật d ữ liệu truyền đi, hạn ch cho params truy n thế ề ẳng phía sau url

• Ví dụ: https://test.com?data=blabla&data1=blabla

• PHẦN USERCONTROLER

o Thêm đoạn code dùng để POST dữ liệu tải lên

o Function này dùng để ạo thêm 1 user và trả t về danh sách user đã được thêm vào phần Content c a ủ HttpresponseMessage

• TIẾN HÀNH GỬI POST REQUEST

o Có thể gửi post ở dạngjsonhoặc urlencoded

o Dữ u tr v liệ ả ề đã thêm user le ngoc son vào danh sách

Để có thể tùy chỉnh chỉ nhận Request gửi đi ở Uri hay chỉ ở Body chúng ta có thể sửa đổi tham số của hàm Ví dụ:

• public HttpResponseMessage CreateNew([FromBody] Users u) // Nhận tham số ở phía Body gửi lên

• public HttpResponseMessage CreateNew([FromUri] Users u) // Nhận tham s ố ở phía Uri

8 2.3 PUT METHOD

Tương tự như Post, chúng ta sẽ thêm 1 hàm để Update thông tin user

PHẦN USERCONTROLER

Thêm 1 hàm dùng để update thông tin user dùng Method là PUT

TIẾN HÀNH GỬI PUT REQUEST

C p nhậ ật thông tin của user 1 bằng cách nhập đúng username cần update, dữ liệu update s ẽ là các thông tin còn lại

Dữ liệu tr v ả ề user 1 đã được cập nhật password, fullname và isactive

9 2.3 DELETE METHOD

PHẦN USERCONTROLER Thêm vào hàm DeleteUser bằng cách truyền vào User và so sánh username (thường thì update hay delete sẽ dùng thuộc tính Id riêng để xác định User c n th c hi n ầ ự ệ

https://swagger.io/docs/

TIẾN HÀNH GỬI DELETE REQUEST

10 Dữ liệu tr v ả ề user 2 đã bị Delete ra khỏi danh sách

3.3 Ưu điểm

• Giúp cho ứng dụng trở nên rõ ràng hơn

• REST URL đại diện cho resource ch ứ không phải là hành động

• Dữ liệu được trả về với nhiều định dạng khác nhau như: xml, html, rss, json …

• Code đơn giản và ngắn gọn

• REST chú trọng vào tài nguyên hệ thống 3.4 Nhược Điểm

Quản lý phiên và trạng thái: REST là stateless, điều này có thể làm tăng phức tạp cho vi c quệ ản lý trạng thái và phiên của người dùng

• Khả năng thực hiện các thao tác không đồng bộ: Đố ới các thao tác không i vđồng bộ như các tác vụ lâu dài hoặc các tác vụ yêu cầu thực hi n m t loệ ộ ạt các bước, REST có thể không phải là lựa chọn tối ưu

• Khả năng truy vấn không linh hoạt: REST không hỗ trợ việc truy vấn phức tạp, ví dụ như truy vấn SQL Điều này có thể làm giảm hiệu suất và linh hoạt của hệ thống trong m t s ộ ố trường hợp

• Không có chuẩn cụ thể: Không có một chuẩn cụ thể nào định nghĩa REST, dẫn đến việc mỗi dự án có thể có cách triển khai khác nhau, điều này có thể gây khó khăn trong việc hiểu và duy trì hệ thống

• Quản lý phiên bản API: Để hỗ trợ các ứng dụng sử dụng API cũ khi API được c p nh t, c n phậ ậ ầ ải duy trì và quản lý các phiên bản API khác nhau • Độ tin cậy và xử lý lỗi: REST không cung cấp một cơ chế chuẩn để xử lý lỗi và đảm bảo độ tin cậy, điều này có thể gây khó khăn trong việc phát hiện và xử lý các lỗi trong h ệ thống

12 Hình 2 API Login

Hình 3 Lấy Danh Sách Sản Phẩm

13

Hình 4 Tạo Mới Sản Phẩm

Hình 5 API Lỗi Khi Chưa Login

14

Hình 6 Tìm Kiếm

Video:

5.2 Kỹ năng phát triển API:

Bạn sẽ có khả năng phát triển và triển khai API RESTful, từ việc thiết kế đến việc xây dựng và kiểm thử

5.3 Trải nghiệm thực tế:

Thực hiện các dự án thực tế sử dụng API RESTful sẽ giúp bạn nắm vững hơn các kỹ năng và kiến thức đã học, đồng thời cải thiện khả năng giải quyết vấn đề và tối ưu hóa hiệu suất của hệ thống

5.4 Đề xuất (mong muốn) của cá nhân về API RESTful

Tài liệu rõ ràng và chi tiết: Để hiểu và sử dụng API RESTful một cách hiệu quả, tôi mong muốn API có tài liệu hướng dẫn rõ ràng, chi tiết, và dễ hiểu Tài liệu nên bao gồm cách sử dụng các endpoint, các phương thức hỗ trợ, và các ví dụ minh họa

5.5 Hỗ trợ cộng đồng:

Tôi mong muốn có một cộng đồng sôi nổi và hỗ trợ chắc chắn từ nhà phát triển và cộng đồng người dùng để giúp đỡ và giải đáp thắc mắc trong quá trình sử dụng API

5.6 Hỗ trợ đa ngôn ngữ và đa định dạng:

Để tối ưu hóa khả năng tích hợp và sử dụng, tôi mong muốn API hỗ trợ nhiều ngôn ngữ lập trình và định dạng dữ liệu khác nhau như JSON, XML, và YAML

5.7 Tính linh hoạt và mở rộng:

16 Tôi mong muốn API có tính linh hoạt và dễ dàng mở rộng để có thể đáp ứng được nhu cầu của các ứng dụng và hệ thống phức tạp

https://books.google.com.vn/books/about/RESTful_API_Design.html?id=DYC3DwAAQBAJ&redir_esc=y

https://restapitutorial.com/#google_vignettehttps://swagger.io/docs/

H T Ế