Tìm hiểu dịch vụ web RESTful và ứng dụng trong xây dựng hệ thống SMSGateway

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ




NGUYỄN THÁI SƠN




TÌM HIỂU DỊCH VỤ WEB RESTful VÀ ỨNG DỤNG
TRONG XÂY DỰNG HỆ THỐNG SMSGATEWAY



LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN





Hà Nội – 2014

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ


NGUYỄN THÁI SƠN


TÌM HIỂU DỊCH VỤ WEB RESTful VÀ ỨNG DỤNG
TRONG XÂY DỰNG HỆ THỐNG SMSGATEWAY


Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN


NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. Võ Đình Hiếu




Hà Nội - 2014

LỜI CẢM ƠN

Trước tiên tôi xin chân thành cảm ơn TS.Võ Đình Hiếu, người đã tận tình hướng

dẫn, giúp đỡ tôi trong suốt quá trình thực hiện luận văn tốt nghiệp;
Tôi xin chân thành cảm ơn các thầy cô giáo khoa Công nghệ Thông tin, trường
Đại học Công nghệ, Đại học Quốc gia Hà Nội, những người đã tận tình truyền đạt các
kiến thức, quan tâm, động viên trong suốt thời gian tôi học tập và nghiên cứu tại trường;
Nhân đây cho phép tôi gửi lời cảm ơn tới nhóm các bạn học cùng lớp
K16CNPM3, lớp chuyên ngành Công nghệ phần mềm đã thường xuyên quan tâm, giúp
đỡ, chia sẻ kinh nghiệm, cung cấp các tài liệu hữu ích trong suốt thời gian học tập tại
Trường và đặc biệt tôi xin chân thành cảm ơn đồng nghiệp ở công ty VNNPLUS, đặc biệt
là phòng kỹ thuật đã hỗ trợ cung cấp các tài liệu và kinh nghiệm trong quá trình thực hiện
luận văn tốt nghiệp vừa qua.


Hà Nội, tháng 07 năm 2014
Tác giả luận văn


Nguyễn Thái Sơn

LỜI CAM ĐOAN
Tôi xin cam đoan bản luận văn “Tìm hiểu dịch vụ web RESTful và ứng dụng
trong xây dựng hệ thống SMSGateway” là công trình nghiên cứu của tôi dưới sự hướng
dẫn khoa học của TS.Võ Đình Hiếu, tham khảo các nguồn tài liệu đã chỉ rõ trong trích
dẫn và danh mục tài liệu tham khảo. Các nội dung công bố và kết quả trình bày trong
luận văn này là trung thực và chưa từng được ai công bố trong bất cứ công trình nào.



Hà Nội, tháng 07 năm 2014
Tác giả luận văn

Nguyễn Thái Sơn

1
Mục lục
Mục lục 1
Danh mục các ký hiệu và chữ viết tắt 4
MỞ ĐẦU 5
Các hệ thống dựa trên dịch vụ web ngày nay 5
Mục tiêu 5
Bố cục luận văn 6
Chƣơng 1: Dịch vụ Web và REST 7
1.1 Tổng quan về dịch vụ web 7
1.2 Kiến trúc và các thành phần của dịch vụ Web 7
1.2.1 XML 8
1.2.2 SOAP 8
1.2.3 WSDL 9
1.2.4 UDDI 11
1.3 XML-RPC 12
1.4 REST là gì? 13
1.5 Nguyên tắc của REST 13
1.5.1 Tài nguyên 14
1.5.2 Khả năng đánh địa chỉ 14
1.5.3 Phi trạng thái 16
1.5.4 Kết nối 16
1.5.5 Giao diện đồng nhất 17
1.5.6 Khả năng lưu cache 18
1.6 Tại sao lại chọn REST 19
1.7 Dịch vụ web RESTful 20
Chƣơng 2- Thƣ viện JAX-RS 22

2
2.1 Giới thiệu 22
2.2 Sử dụng thư viện JAX-RS 22
2.2.1 Tạo mới một customer 23
2.2.2 Nhận thông tin customer 24
2.2.3 Cập nhật customer 25
2.3 Các toán tử HTTP và ánh xạ URI 26
2.3.1 Các toán tử ràng buộc của HTTP 26
2.3.2 Ký hiệu @Path và tùy chọn mở rộng 27
2.4 Ánh xạ JAX-RS 28
2.4.1 Các ký hiệu ánh xạ lấy thông tin cơ bản 28
2.4.2 @PathParam 29
2.4.3 @QueryParam 31
2.4.4 @FormParam 32
Chƣơng 3: Bảo mật với dịch vụ RESTful 34
3.1 Giới thiệu 34
3.2 Kiểu kiến trúc REST phù hợp với bộ đệm web 35
3.3 Khóa mã hóa nội dung đối xứng 36
3.4 Thảo luận về giải pháp 37
3.5 Kết luận 38
3.6 Áp dụng bảo mật dịch vụ web RESTful 40
3.6.1 Bảo mật dịch vụ web RESTful bằng cách cấu hình web.xml 40
3.6.2 Bảo mật dịch vụ web RESTful bằng cách sử dụng SecurityContext 41
3.6.3 Bảo mật dịch vụ web RESTful bằng cách sử dụng ký hiệu 43
Chƣơng 4- Thiết kế và hiện thực hệ thống SMSGateway 45
4.1 Giới thiệu hệ thống 45
4.2 Nguyên tắc hoạt động 45
3
4.3 Hệ thống SMSGateway 46
4.4 Mục tiêu áp dụng REST 48

4.5 Tài nguyên 48
4.6 Đánh địa chỉ 49
4.7 Phi trạng thái 50
4.8 Liên kết với nhau 50
4.9 Giao diện đồng nhất 51
4.10 Khả năng cache 52
4.11 Cấu trúc REST API 53
4.12 Các lược đồ tuần tự 55
4.12.1 Lấy danh sách MO bằng thao tác GET 55
4.12.2 Lấy một MO bằng thao tác GET 57
4.12.3 Tạo mới một MO bằng thao tác POST 59
4.12.4 Update một MO bằng thao tác PUT 59
4.12.5 Xóa MO bằng thao tác DELETE 59
4.12.6 Tìm kiếm MO 62
Chƣơng 5- Prototype 64
5.1 Giới thiệu 64
5.2 Một số đoạn code mô tả thực thi API 64
5.3 Test API với Google Chrome 68
5.4 Test API với giao diện ứng dụng 70
KẾT LUẬN 73
TÀI LIỆU THAM KHẢO 74
PHỤ LỤC 75

4
Danh mục các ký hiệu và chữ viết tắt
REST: Representational State Transfer(Chuyển đổi trạng thái đại diện)
MO: Mobile Originated(Tin nhắn đến)
MT: Mobile Terminated (Tin nhắn đi)
SMS: Short Message Service (Tin nhắn)
XML: Extensible Markup Langguage (Ngôn ngữ đánh dấu mở rộng)

SOAP: Simple Object Access Protocol (Giao thức truy cập đối tượng đơn giản)
WSDL: Web Service Description Langguage (Ngôn ngữ mô tả dịch vụ)
UDDI: Universal Description, Discovery và Integration
HTTP: Hypertext Transfer Protocol (Giao thức truyền tải nội dung siêu văn bản)
W3C: World Wide Web Consortium (Tổ chức World Wide Web)
RPC: Remote Procedure Call (Triệu gọi thủ tục từ xa)
JAX-RS: Java API for RESTful Web Services (Thư viện API cho dịch vụ web RESTful)
URI: Uniform resource identifier (Xác định tài nguyên đồng nhất)
API: Application programming interface (Giao diện lập trình ứng dụng)

5
MỞ ĐẦU
Các hệ thống dựa trên dịch vụ web ngày nay
Hệ thống dựa trên nền web là hệ thống mà cho phép những ứng dụng hoặc dịch vụ đang
cư trú trên một máy chủ có thể được truy cập bằng cách sử dụng một trình duyệt web nào
đó và có thể truy cập từ bất cứ nơi nào trên thế giới thông qua web [8]. Đó là một hệ
thống bao gồm một tập hợp các tổ chức phức tạp và chặt chẽ như thị trường, dịch vụ, các
giao dịch liên kết với nhau. Giao dịch được hiểu là sự kiện hoặc khởi tạo tiến trình hoặc
một người dùng hay chương trình máy tính nào đó yêu cầu, và mỗi giao dịch đó được coi
là một một đơn vị công việc duy nhất cần phải phải lưu một bản ghi log vào dữ liệu hệ
thống, trong hoàn cảnh này mỗi giao dịch được xác định là một đơn vị duy nhất và kết
thúc một trong hai trường hợp là thành công hoặc không thành công. Hơn nữa mỗi giao
dịch bắt buộc phải được ghi log lại cho dù nó thành công hay thất bại để hệ thống biết
được rằng đã có giao dịch xảy ra.
Những hệ thống dựa trên nền web ngày nay có nhiều yêu cầu phức tạp đảm bảo khả năng
tồn tại 100%, có thể xử lý số lượng lớn các giao dịch và sử dụng các giao thức truyền
thông tiêu chuẩn để có thể tự động tương tác với các hệ thống khác.
Mục tiêu
Cho đến nay thì hầu hết các hệ thống dựa trên nền web sử dụng thư viện XML-RPC cung
cấp một API cho máy tính giao tiếp với máy tính và một API cho con người giao tiếp với

máy tính. Điều này thể hiện một vấn đề thực tế rằng trong nhiều trường hợp các dịch vụ
tương tự được cung cấp bởi cả hai API, có nghĩa là sẽ gấp đôi số lượng công việc khi
phát triển cũng như lúc bảo trì nâng cấp hệ thống. Hơn nữa các API này vẫn có nhược
điểm.
Nhiều cuộc điều tra về một loại kiến trúc có tên là REST [7,15] đã được thực hiện và kết
quả cho thấy REST là một giải pháp thích hợp cho vấn đề này. Kết quả của các cuộc điều
tra đưa đến kết luận để thiết kế web service theo kiến trúc REST như sau:
 Hiểu được các nguyên tắc của REST.
 Hiểu được loại dữ liệu được điều khiển bởi các hệ thống dựa trên nền web.
6
 Đưa ra được phương pháp xây dựng cách thức truy cập dữ liệu sử dụng API
REST.
 Tiến hành cài đặt API RESTful theo phương pháp trên.
 Cho thấy rằng API vừa cài đặt có thể dùng chung cho cả người và máy.
Bố cục luận văn
Chương 1: Giới thiệu chung về dịch vụ web, kiến trúc và các thành phần cơ bản của dịch
vụ web như XML, SOAP, WSDL và UDDI từ đó đưa ra mục tiêu phát triển luận văn,
cũng trong chương này sẽ giới thiệu về REST, mô tả từ khóa REST ngày nay rất phù hợp
với nền tảng cơ bản với dịch vụ web, đưa ra lý do tại sao chọn REST để phát triển dịch
vụ web, và phần giới thiệu hệ thống mà sau này tác giả có ý định phát triển dịch vụ
RESTful cũng được giới thiệu trong phần này.
Chương 2: Giới thiệu thư viện JAX-RS và cách sử dụng thư viện vào việc lập trình phát
triển dịch vụ web, các tính năng cũng như các toán tử của thư viện JAX-RS cũng sẽ được
trình bày ở chương này.
Chương 3: Chương này giới thiệu các phương pháp bảo mật cơ bản cũng như cách thực
hiện và áp dụng vào hệ thống sẽ được tác giả trình bày trong chương này.
Chương 4: Chương này sẽ giới thiệu chi tiết về hệ thống SMSGateway, nguyên tắc hoạt
động của hệ thống cũng như mục tiêu mà hệ thống cần đạt được, áp dụng các nguyên tắc
của REST và sử dụng thư viện JAX-RS để thiết kế các dịch vụ web RESTful ứng dụng
vào hệ thống SMSGateway, ngoài ra các lược đồ tuần tự ở cấp độ cao sẽ được thiết kế và

chỉ ra trong chương này để ta có thể thấy được REST API phân biệt các môđun khác
nhau như thế nào và tương tác như làm sao.
Chương 5: Chương này sẽ giới thiệu các đoạn code mô tả các tiến trình phát triển ứng
dụng và cung cấp một một vài tool để có thể kiểm chứng ứng dụng thực hiện các yêu cầu
REST API.

7
Chƣơng 1: Dịch vụ Web và REST
Chương này sẽ giới thiệu tổng quan về dịch vụ web, kiến trúc, thành phần cơ bản, cũng
trong chương này chúng ta sẽ tìm hiểu nguồn gốc từ REST và ý nghĩa của nó, tại sao
chúng ta lựa chọn REST thay thế mà không phải là cái khác, giới thiệu những ý tưởng cơ
bản của REST, các đặc điểm chính và lý do tại sao chúng ta lại sử dụng REST
1.1 Tổng quan về dịch vụ web
Theo định nghĩa của W3C (World Wide Web Consortium) [8] thì một dịch vụ web là một
hệ thống phần mềm được xây dựng sẵn các tính năng cần thiết, hay còn gọi là các
phương thức theo chuẩn để hỗ trợ sự tương tác giữa máy tính và máy tính, giữa người và
máy tính. Dịch vụ web cung cấp một API được mô tả theo một định dạng chung gọi là
ngôn ngữ mô tả dịch vụ web (Web Service Description Language) viết tắt là WSDL [11].
Người dùng hoặc máy tính thực hiện tương tác với dịch vụ web thông qua giao thức
SOAP (Simple Object Access Protocol) [10]. Đây là một trong các giao thức được sử
dụng để trao đổi thông tin trên mạng phổ biến nhất hiện nay sử dụng HTTP (Hypertext
Transfer Protocol) [2,3,4] kết hợp với việc sử dụng XML cùng với một số chuẩn khác.
Như vậy ta thấy mục đính chính của dịch vụ web là cho phép trao đổi và tương tác thông
tin, các chức năng, dữ liệu giữa các ứng dụng một cách dễ dàng mà không cần quan tâm
đến môi trường phát triển cũng như ngôn ngữ lập trình bởi tất cả đã cả được quy về một
định dạng chung. Ngoài ra bản chất của dịch vụ web là một tập hợp các đối tượng, các
phương thức được thực thi và công bố lên mạng để có thể triệu gọi được từ xa thông qua
các ứng dụng khác nhau.
1.2 Kiến trúc và các thành phần của dịch vụ Web
Công nghệ dịch vụ web không phải là một công nghệ mới, mà công nghệ này ra đời dựa

trên các nền tảng công nghệ sẵn có trước đó. Công nghệ này là sự kết hợp các ứng dụng
dựa trên nền web sử dụng các chuẩn mở như XML, SOAP, WSDL, UDDI [8]. Trong đó
XML được sử dụng để mô tả dữ liệu, SOAP đóng vai trò giao thức truyền tải dữ liệu,
WSDL đóng vài trò mô tả cho dịch vụ web còn UDDI đóng vai trò cung cấp danh sách
các dịch vụ web đang hoạt động. Chi tiết về các chuẩn mở này chúng ta sẽ bàn chi tiết
trong phần sau, phần các thành phần cơ bản của dịch vụ web.
8

1.2.1 XML
XML (Extensible Markup Langguage) là một chuẩn do W3C đề ra và được phát triển từ
SGML, XML là một ngôn ngữ đánh dấu mở rộng với cấu trúc do lập trình viên phát triển
dịch vụ tự định nghĩa. Về hình thức thì XML hoàn toàn có cấu trúc thẻ giống như HTML,
nhưng HTML định nghĩa thành phần được hiện thị như thế nào thì XML lại định nghĩa
những thành phần đó chứa những cái gì. Hay nói cách khác XML có cú pháp tương tự
HTML nhưng không tuân theo một đặc tả quy ước như HTML. Người sử dụng hoặc các
chương trình có thể quy ước định dạng các thẻ XML. Dịch vụ web là sự kết hợp của
nhiều thành phần khác nhau, và dịch vụ này hỗ trợ tương tác giữa các hệ thống được cài
đặt trên môi trường khác nhau. Do đó cần phải sử dụng một loại tài liệu đồng nhất giúp
giải quyết được vấn đề tương thích và XML hoàn toàn phù hợp với yêu cầu trên. XML đã
trở thành nền tảng cho việc xây dựng các dịch vụ web và XML có hai chức năng chính:
 Trao đổi thông tin dữ liệu trong hệ thống sử dụng dịch vụ web
 Mô tả các giao thức sử dụng trong dịch vụ web
1.2.2 SOAP
SOAP (Simple Object Access Protocol) là một giao thức dùng để truy xuất các thông tin
từ dịch vụ web thông qua một thông điệp chung. SOAP được Microsoft đề xuất vào năm
1998, hiện nay SOAP thuộc quyền quản lý và cải tiến của tổ chức W3C. SOAP là một
giao thức dựa trên nền tảng XML, mô tả cách định dạng, đóng gói thông tin của các
Hình 1.1: Mô hình kiến trúc dịch vụ web
9
thông điệp và trao đổi chúng thông qua mạng mà không phụ thuộc bất kỳ môi trường

thực thi hay ngôn ngữ lập trình nào. Đơn vị trao đổi thông tin cơ bản của SOAP là thông
điệp SOAP (SOAP Message). Mỗi thông điệp SOAP sẽ được dùng bởi một thẻ gốc là
<Envelope> trong đó chứa 2 thẻ thành phần là SOAP Header và SOAP Body. SOAP
Header chứa các thông tin cần thiết cho việc thực hiện chuyển thông điệp hay cơ chế định
danh, bảo mật. SOAP Body chứa dữ liệu ứng dụng. Cấu trúc của một thông điệp SOAP
như hình sau:

1.2.3 WSDL
WSDL (Web Service Description Langguage) là một tài liệu đặc tả dựa trên chuẩn ngôn
ngữ XML để mô tả các dịch vụ web. Ban đầu WSDL được Microsoft và Ariba đề xuất,
nhưng hiện nay WSDL được quản lý và phát triển bởi W3C. Mỗi một đặc tả WSDL sẽ
cung cấp tài liệu cho các hệ thống phân tán cũng như mô tả chức năng của một dịch vụ
web, cách thức tương tác, các thông điệp tương tác cho các yêu cầu theo request hay
response. Sau đây là cấu trúc cơ bản của một tài liệu:
Hình 1.2: Cấu trúc của một thông điệp SOAP
10


Một đặc tả WSDL bao gồm 2 phần chính: phần trừu tượng (Abstract definitions) và phần
cụ thể (Concrete definitions), phần trừu tượng bao gồm các thông tin được chứa trong các
thẻ types, message và portypes. Phần cụ thể bao gồm các thông tin được chứa trong các
thẻ bindings và ports. Mỗi thành phần sẽ có một tham chiếu đến một thành phần khác
được mô tả như hình sau:


Hình 1.4:Các thành phần của WSDL
Hình 1.3:Cấu trúc của WSDL
11
Mỗi một thành phần có một chức năng riêng, cụ thể như sau:
 Types: chỉ ra kiểu dữ liệu cho các thông điệp gửi và nhận

 Messages: là một thành phần trừu tượng mô tả cách thức giao tiếp giữa máy khách
và máy chủ.
 Porttypes: mô tả ánh xạ giữa các thông điệp, được mô tả trong phần tử messages
và các phương thức (operations).
 Binding: xác định giao thức nào được sử dụng khi giao tiếp với dịch vụ web, định
nghĩa kiểu binding và giao thức vận chuyển binding cũng định nghĩa các
operations.
 Port: chỉ định địa chỉ và cổng kết nối tới dịch vụ web, thường là một địa chỉ URL
đơn giản.
1.2.4 UDDI
UDDI (Universal Description, Discovery và Integration) cũng được Microsoft, IBM và
Ariba đề xuất năm 2000. Ngày nay UDDI thuộc quyền sở hữu và phát triển của tổ chức
OASIS (Organization for the Advancement of Structured Information Standards). UDDI
được xây dựng nhằm mục đính cung cấp khả năng cho phép công bố, tổng hợp và tìm
kiếm các dịch vụ web. UDDI đưa ra một tập hợp các hàm API được chia làm 2 phần:
Inquiry API, dùng để tìm kiếm và truy xuất các dịch vụ web đã đăng ký và Publisher „s
API, dùng để công bố các dịch vụ web muốn đăng ký. Thông tin tổ chức trong UDDI
được chia làm 3 phần:
 White pages: liệt kê thông tin của các nhà cung cấp dịch vụ web, bao gồm địa chỉ,
thông tin liên lạc và định danh.
 Yellow pages: phân loại dịch vụ theo tổ chức hay nhóm dịch vụ hoặc địa điểm đặt
các dịch vụ.
 Green pages: cung cấp thông tin về các dịch vụ web, cách thức truy cập cũng như
tương tác với các dịch vụ web đó.
12
1.3 XML-RPC
XML-RPC được kế thừa từ RPC và World Wide Web, sử dụng lại ý tưởng và nền tảng
về việc tạo ra sự giao tiếp giữa con người với nhau để hỗ trợ việc giao tiếp giữa các
chương trình trên máy tính.
Mặc dù web là công cụ giao tiếp giữa con người với con người, sau đó được tiến hóa một

cách tinh tế để làm công cụ giao tiếp giữa con người và máy tính, cuối cùng chuyển sang
dạng truyền thông phức tạp giữa máy tính và máy tính
HTML thực sự đã rất thành công, nhưng thực tế mới chỉ hữu ích cho các giao dịch hiển
thị thông tin cho con người. Vì lý do đó, W3C tổ chức phát triển eXtensible Markup
Language (XML), một ngôn ngữ đánh dấu cung cấp linh hoạt hơn HTML về việc giao
tiếp giữa các chương trình.
XML được truyền giữa các máy tính sử dụng giao thức HTTP thông qua RPC, sử dụng
HTTP có nghĩa là các yêu cầu XML-RPC phải được đồng bộ và phi trạng thái, một yêu
cầu XML-RPC luôn luôn có một trả lời XML-RPC tương ứng, bởi vì yêu cầu và trả lời
đều phải xảy ra trên cùng một kết nối HTTP. XML cũng có khả năng thực thi hệ thống
không đồng bộ, nhưng trong nhiều trường hợp chi phí để tạo ra hệ thống đó là điều không
thể. Nói chung các yêu cầu không đồng bộ có khả năng thực hiện nhiều yêu cầu của tiến
trình hơn.
Phi trạng thái (stateless) có nghĩa là không có nội dung được hiểu từ yêu cầu này đến yêu
cầu tiếp theo. Bản thân XML-RPC cũng không có cách khác là xem chúng như hai yêu
cầu riêng biệt không liên quan đến nhau. Điều này nhiều khi có thể tránh được các chi phí
lớn liên quan đến việc bảo trì hệ thống. XML-RPC không cung cấp hỗ trợ duy trì trạng
thái, nhưng với một hệ thống với statefull thì XML-RPC có thể thực hiện hỗ trỡ duy trì
trạng thái.
Với các điểm chính về công nghệ liên quan đến XML-RPC như trên thì XML-RPC có
các nhược điểm như sau:
13
 Một yêu cầu XML-RPC bao gồm hành động để thực hiện và các tham số của hành
động đó trong yêu cầu gửi lên HTTP khi mà HTTP đã sẵn sàng đáp ứng yêu cầu
và trả lời yêu cầu.
 Một API XML-RPC thì cần phải định nghĩa mã lỗi riêng của nó, khi đó sẽ dễ dàng
sử dụng trạng thái mã lỗi hơn.
 Với kiểu API sử dụng XML-RPC thì các chức năng về xác thực và cache bên phía
máy khách không thể thực hiện được trong hệ thống này.
Một giải pháp mới có thế thay thế XML-RPC để khắc phục các nhược điểm của XML-

RPC đó chính là dịch vụ RESTful. Chúng ta sẽ tìm hiểu dịch vụ này chi tiết hơn trong
chương 2 và chương 3 để có thể hiểu REST được thay thế XML-RPC như thế nào.
1.4 REST là gì?
REST (Representational State Transfer) là một kiểu kiến trúc được định nghĩa bởi Roy
Fielding [6]. Mục đính của REST là thiết kế các ứng dụng mạng phân tán sử dụng HTTP
như là một giao thức tầng ứng dụng và nó là một mô hình kiến trúc thực sự cho web.
1.5 Nguyên tắc của REST
Như một hệ quả tất yếu của quá trình phức tạp ngày càng lớn của các dịch vụ web lớn
nên RESTful đã được đưa ra như là một giải pháp để thay thế việc thực hiện triệu gọi từ
xa (RPC) thông qua web.
Web dựa vào tài nguyên, nhưng các dịch vụ web lớn lại không dựa vào tài nguyên. Web
dựa vào URI và liên kết nhưng các dịch vụ web lớn lại không dựa vào chúng. Web dựa
vào HTTP và các tính năng của nó, nhưng các dịch vụ web hầu như không dựa vào bất
kỳ tính năng nào của HTTP. Vấn đề này không phải là các dịch vụ web lớn không nhận
ra mà nó cảm thấy không nhận được lợi ích gì từ dịch vụ web hướng tài nguyên. Chúng
không có khả năng đánh địa chỉ, không cache, kết nối không tốt. Chúng cũng không cần
giao diện đồng nhất. Chúng không được rõ ràng, hiểu được một vấn đề không giúp mình
hiểu được vấn đề tiếp theo, trong thực tế chúng cũng có vấn đề khi tương tác với nhiều
khách hàng cùng một lúc.
REST là một kiểu kiến trúc cho hệ thống phân tán như World Wide Web. Để thực thi
kiến trúc RESTful ta cần phải tuân thủ theo hướng dẫn của ROA, kiến trúc hướng tài
nguyên, trong tài liệu này sẽ có các quy tắc cho phép ta thiết kế dịch vụ RESTful [6].
14
Kiến trúc REST cũng phải dựa vào các nguyên tắc [7,12,13] như mô tả trong các tài liệu,
đó là Tài nguyên(Resources), Khả năng đánh địa chỉ(Addressability), Phi trạng
thái(Statelessness), Kết nối(Connectedness), Giao diện đồng nhất(Uniform Interface) và
Khả năng lưu cache(Cacheability).
1.5.1 Tài nguyên
Mọi thứ mà dịch vụ cung cấp đều là tài nguyên như khách hàng, xe hơi, tranh ảnh, giọng
nói, cửa hàng thương mại điện tử,v.v… tài nguyên có thể là một đối tượng vật lý cũng có

thể là một khái niệm trừu tượng nào đó. Mọi tài nguyên đều có duy nhất một URI(với
một mã duy nhất). Nếu một thông tin nào đó không có URI thì nó không phải là tài
nguyên và không tồn tại trên mạng.
Hai tài nguyên không thể có cùng một URI (xem hình 1.5) nhưng hai URI có thể trỏ vào
cùng một tài nguyên vào cùng một thời điểm (xem hình 1.6). Ví dụ chúng ta có một URI
xác định http://server/last_version và một URI xác định một tài nguyên khác
http://server/last_version_1.3, khi last_version hiện tại là phiên bản 1.3 thì cả hai URI đều
cùng trỏ vào một tài nguyên. Sau một thời gian thì last_version lên phiên bản mới là 1.4,
lúc đó hai URI này sẽ trỏ vào hai tài nguyên khác nhau.



1.5.2 Khả năng đánh địa chỉ
Hình 1.5:Hai tài nguyên cùng một uri
Hình 1.6: Hai uri cùng trỏ đến một tài nguyên
15
Mọi tài nguyên đều được đánh địa chỉ, mỗi tài nguyên đều được đánh địa chỉ có nghĩa là
sẽ có đủ URI để đánh địa chỉ cho mọi tài nguyên, với khả năng đánh địa chỉ chúng ta có
thể lưu lại các trang thông tin cần thiết, cũng có thể gửi URI này tới người khác như là
một tài nguyên, đặc biệt với khả năng lưu cache, thì tài nguyên được lưu ở máy khách,
sau lần truy cập đầu tiên thì tài nguyên sẽ được truy cập ở máy khách.
Chúng ta cùng xem xét qua ứng dụng của Google Maps, vào ứng dụng Google Maps
chúng ta gõ “Nguyễn Trãi, Hanoi, Vietnam” hệ thống Google Maps sẽ hiện thị ra một số
địa chỉ mà liên quan đến từ khóa ta vừa gõ, ta thấy URI của site
không thay đổi, điều đó có nghĩa là không phải Google Maps không có khả năng đánh
địa chỉ, có nghĩa rằng ứng dụng web mà chúng ta đang sử dụng thì không có khả năng
đánh địa chỉ mà cái khả năng đánh địa chỉ chính là dịch vụ web. Nếu chúng ra muốn gửi
thông tin bản đồ này cho người khác thì chúng ta cần yêu cầu ứng dụng một URI mà có
thể gửi cho người khác mà vẫn xem được đúng hình ảnh bản đồ mà mình đang xem. Nếu
không có khả năng đánh địa chỉ thì chúng ta không thể cho người khác xem bản đồ mà

mình đang xem.

Hình 1.7: Minh họa việc gửi địa chỉ
16
1.5.3 Phi trạng thái
Mọi yêu cầu HTTP đều hoàn thành một cách riêng biệt nhau. Có nghĩa rằng khi ở máy
khách tạo một yêu cầu HTTP thì tất cả các thông tin trong yêu cầu đó phải được đệ trình
lên máy chủ. Dịch vụ thường không dựa vào thông tin của các yêu cầu trước. Nếu máy
chủ yêu cầu dữ liệu của yêu cầu trước thì máy khách phải gửi lại thông tin đó xem như là
một yêu cầu mới, máy chủ không giữ bất kỳ thông tin gì của máy khách cả.
Điều này làm cho hệ thống đáng tin cậy hơn, đơn giản hơn và khả năng mở rộng lớn hơn.
Một máy khách thực hiện yêu cầu đến máy chủ A, một máy khách khác thực hiện một
yêu cầu khác tới máy chủ A, vào thời điểm đó máy chủ A lỗi thì nột máy chủ khác được
thay để xử lý các yêu cầu mà máy khách đã gửi, điều này có nghĩa là máy chủ web được
thay thế một cách dễ dàng và làm cho hệ thống có khả năng thay đổi, đặc biệt nếu trong
hệ thống có sự cân bằng tải thì máy chủ sẽ phục vụ tốt hơn đối với các người dùng mà đã
yêu cầu trước đó, với cân bằng tải này thì hệ thống sẽ trở nên đơn giản hơn để thực hiện.
1.5.4 Kết nối
Dịch vụ RESTful cho phép các máy khách chuyển từ trạng thái này đến trạng thái khác
bằng cách gửi các liên kết trong các đại diện với nhau, đại diện có thể là siêu âm thanh,
có thể là tài liệu mà trong đó không chỉ chứa mỗi dữ liệu mà có thể còn có cả các liên kết
tới các tài nguyên khác nữa. Tất cả các tài nguyên thì nên kết nối và liên kết với nhau, nó
cho phép các máy khách biết được nhau bằng cách duyệt các siêu liên kết trong các đại
diện tài nguyên.


Hình 1.8: Sự liên kết giữa các máy khách
17
1.5.5 Giao diện đồng nhất
Máy khách tương tác với hệ thống thông qua các phương thức của HTTP: GET, POST,

PUT, DELETE. Các phương thức này định nghĩa được những thứ mà có thể làm với một
tài nguyên
HTTP GET
Phương thức GET có nghĩa là nhận bất kỳ thông tin gì, trong trường hợp thông tin dữ liệu
là dạng form thì được xác định bởi một yêu cầu URI [2], còn trong trường hợp là dịch vụ
web RESTful thì thông tin này được xác định bằng một URI là đại diện của một tài
nguyên.
GET là phương thức an toàn và không thay đổi. An toàn ở đây có nghĩa là nó không làm
thay đổi trạng thái của máy chủ, nó chỉ nhận thông tin thôi nên nó không làm ảnh hưởng
gì đến máy chủ, không thay đổi ở đây có nghĩa là có thể nhiều yêu cầu giống hệt nhau mà
có thể cho kết quả như nhau. Từ khi giao thức HTTP là một giao thức phi trạng thái thì
cũng được quy định là an toàn và không đổi. Sử dụng tính chất không đổi cho phép GET
lấy lại tài nguyên lặp nếu gặp lỗi.
Nếu yêu cầu thành công và kết quả là một tài nguyên được trả về thì thông điệp trạng thái
trả về phù hợp với yêu cầu đó là 200 (thành công). Nếu tài nguyên không tồn tại thì trạng
thái trả về là 404 (không thành công, tài nguyên không tìm thấy).
Nếu thông điệp yêu cầu có chứa cả các trường phạm vi, điều kiện thì ngữ nghĩa của
phương thức GET có thay đổi một chút. Phương thức này giảm thiểu sự sử dụng mạng
không cần thiết bằng cách cho phép nhận một phần thông tin để hoàn thành phương thức
GET mà không cần phải chuyển hết dữ liệu mà máy khách đang giữ.
HTTP POST
Phương thức POST được sử dụng để yêu cầu tạo tài nguyên mới với dữ liệu đính kèm
theo yêu cầu.
Nếu yêu cầu POST mà không trả về kết quả, tài nguyên có thể được xác định bởi URI,
trạng thái trả về nếu thành công là 200 (thành công). Nếu tạo tài nguyên mới thì trạng thái
18
trả về là 201 (tạo tài nguyên mới) và chứa đựng thông tin mô tả trạng thái của yêu cầu và
tham chiếu tới tài nguyên mới ở phần header của thông tin.
HTTP PUT
Phương thức PUT yêu cầu thực thể đính kèm được cung cấp theo cùng yêu cầu URI.

Nếu URI tham chiếu tới tài nguyên đã tồn tại thì thực thể kèm theo sẽ được xem xét thay
đổi ở trên máy chủ. Nếu tài nguyên đó chưa tồn tại thì có khả năng URI đó yêu cầu một
tài nguyên mới, máy chủ sẽ phải tạo một tài nguyên mới với URI đó, nếu tài nguyên mới
được tạo thì trạng thái trả về là 201, nếu tài nguyên đã tồn tại tức là thay đổi tài nguyên
thì trạng thái trả về là 200. Nếu tài nguyên mới không được tạo, cũng không thay đổi tài
nguyên cũ thì một trạng thái mã lỗi sẽ được trả về thông báo lỗi tương ứng.
Phương thức POST và PUT trông có vẽ giống nhau, tuy nhiên chúng khác nhau về mặt ý
nghĩa trong các yêu cầu của chúng, trong phương thức PUT thì URI định nghĩa các thực
thể đính kèm với yêu cầu (ở máy khách đã chỉ ra ID của tài nguyên trong URI đó).
Ngược lại trong phương thức POST trong URI yêu cầu định nghĩa tài nguyên mà sẽ điều
khiển thực thể kèm theo. Hơn nữa PUT là một phương thức không thay đổi (giống như
GET) nhưng POST thì ngược lại.
HTTP DELETE
Phương thức DELETE yêu cầu máy chủ xóa tài nguyên được xác định trong yêu cầu, nó
cũng là một phương thức không thay đổi như phương thức GET và PUT. Nếu xóa thành
công thì mã trạng thái 200 (thành công) sẽ được trả về, ngược lại nếu không thành công
thì một trạng thái mã lỗi tương ứng sẽ được trả về một cách phù hợp.
1.5.6 Khả năng lƣu cache
Tài nguyên thì nên được cache lại đâu đó trên máy khách với một điều kiện và một
khoảng thời gian nào đó. Cơ chế cache thì làm cho người dùng có thể tải tài nguyên tốt
hơn, nhanh hơn, có thể giảm tải được cho máy chủ về cả mặt thời gian và lưu lượng. Có
hai cơ chế cache trong HTTP đó chính là thời hạn và xác thực. Theo RFC2616 [2] thì
mục tiêu của cache trong HTTP/1.1 đó là trong nhiều trường hợp loại trừ khả năng gửi
yêu cầu đến máy chủ, giảm thiểu số lượng yêu cầu vào trong qua mạng, cũng loại trừ khả
năng gửi kết quả trả lại trong nhiều trường hợp khác, điều này cũng giảm thiểu được băng
19
thông trên máy chủ, nếu các yêu cầu cũ thì thông qua cơ chế thời hạn, nếu các yêu cầu là
mới thì thông qua cơ chế xác nhận. Phương thức POST thì không có khả năng cache nếu
không có sự điều khiển cache phù hợp, phương thức GET được thiết kết là có ý định cho
phép cache.

Thời hạn
Thời hạn là cách để máy chủ thông báo cho tài nguyên được yêu cầu bao nhiêu lâu thì
được cache lại trên máy khách.
Thời hạn ở header
Thời hạn ở header chỉ cho bạn biết ngày giờ tài nguyên sẽ hết hạn, việc này có một điều
kiện là ngày giờ của máy chủ và máy khách phải đồng bộ với nhau.
Điều khiển cache ở header
Trong HTTP/1.1 có thể thay thế thời hạn ở header bằng cách điều khiển cache ở header,
để giải quyết vấn đề đồng bộ của máy chủ và máy khách, làm cho khả năng cache linh
hoạt hơn. Điều khiển cache ở header có một tập các mệnh đề điều kiện, được dùng để
điều khiển máy khách cache tài nguyên như thế nào [14].
Xác nhận
Xác nhận cho phép máy khách yêu cầu máy chủ xem phiên bản cache của tài nguyên, xác
nhận rằng tài nguyên còn dùng được nữa hay không.
1.6 Tại sao lại chọn REST
Với các nguyên tắc và các lợi ích như đã trình bày ở trên mà REST có thể đưa lại thì có
thể đưa ra một số lý do chọn REST như sau:
Thứ nhất, mỗi đối tượng vật lý hoặc khái niệm trừu tượng đều có thể xem như một tài
nguyên duy nhất, điều này có nghĩa rằng chúng sẽ được truy cập nhanh chỉ với một yêu
cầu duy nhất ngay sau khi chúng được xác định, với điều này thì cũng tạo dễ dàng cho
người dùng và giảm tải cho máy chủ nếu như tài nguyên chỉ truy cập với một yêu cầu duy
nhất.
20
Thứ hai, với nguyên tắc phi trạng thái thì REST làm cho hệ thống linh động tốt hơn khi
mà máy chủ không bắt được thông tin của máy khách, điều này có nghĩa rằng các máy
chủ được kết nối với hệ thống đều có thể nhận bất kỳ yêu cầu nào từ máy khách và trả lời
máy khách một cách phù hợp. Các ảnh hưởng khác của nguyên tắc này đó là cân bằng tải
phức tạp không cần thiết và máy khách đang sử dụng hệ thống mà máy chủ bị mất kết nối
thì máy chủ cũng không phải thông báo cho máy khách và xem đó là lỗi của hệ thống.
Thứ ba, nếu dịch vụ không theo RESTful thì các dịch vụ rất khó để có thể liên kết với

nhau vì các tài nguyên không có khả năng đánh địa chỉ, chúng không kết nối được với
nhau, các phương thức của HTTP sử dụng trong mỗi yêu cầu không theo một mẫu chuẩn.
Theo kiểu kiến trúc REST thì máy khách có thể đoán được giao diện tương tác được thiết
kế như thế nào và kết nối trực tiếp với thông tin cần thiết sử dụng URI chỉ định hoặc điều
hướng qua đại diện sử dụng các liên kết.
Thứ tư, khả năng lưu cache có thể dễ dàng sử dụng, làm giảm tải cho máy chủ và cải
thiện thời gian cho máy khách.
Với các lợi ích như trên thì REST là một kiểu kiến trúc thú vị và hấp dẫn, rất đáng để sử
dụng vì nó có thể cải thiện dịch vụ theo nhiều cách có thể.
1.7 Dịch vụ web RESTful
Với khái niệm dịch vụ RESTful có nghĩa là một dịch vụ web mà áp dụng các nguyên tắc
của REST để thiết kế và phát triển gọi là dịch vụ RESTful. REST là kiểu kiến trúc tầng
dưới của web, bởi vậy áp dụng các nguyên tắc REST có nghĩa là sẽ tích hợp trực tiếp vào
web hơn là tập trung vào các chức năng. Dịch vụ RESTful sử dụng tài nguyên web như là
các khái niệm trừu tượng chính [4,6].
Dịch vụ RESTful có rất nhiều lợi thế mà web đã đưa ra, các lợi thế có thể kể ra như sau:
 Các kiểu dữ liệu chuẩn và phổ biến được sử dụng để mô tả dữ liệu, các loại dữ liệu
này cũng được dùng để mô tả tài nguyên ở phía máy khách tùy theo yêu cầu của
máy khách, ví dụ kết quả dữ liệu thống kê thì có thể được cung cấp trong HTML
cho người dùng có thể đọc được, trong khi đó ở một số máy khách thì có thể áp
dụng vào excel để tính toán dữ liệu.
21
 Giao diện đồng nhất được cung cấp từ khi phương thức HTTP chuẩn được sử
dụng
 Thực sự độc lập ngôn ngữ.
 Khi sử dụng HTTP thì vượt qua tường lửa không phải là vấn đề.
 Lưu cache có thể làm tăng khả năng thực hiện.
 HTTP được sử dụng trong tầng ứng dụng, bởi vậy tất cả các tính năng chuẩn của
HTTP được kết thừa vào trong dịch vụ RESTful, các tính năng quan trọng như mã
hóa, xác thực và cache.

Các vấn đề thuận lợi này được cung cấp phổ biến trong dịch vụ web 2.0 để phát triển dịch
vụ RESTful như Yahoo, Amazon, Flickr.