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

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

ĐẠ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

ĐẠ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

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

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

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

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)

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

 Đư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

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

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

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

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

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

 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 đó

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:

 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ế RPC để khắc phục các nhược điểm của 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

XML-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

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

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 http://maps.google.com/ 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

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

Hình 1.8: Sự liên kết giữa các máy khách

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ữ

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

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

Đ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

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

 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

Chương 2- Thư viện JAX-RS

2.1 Giới thiệu

Trong vài năm gần đây thì việc xây dựng dịch vụ RESTful trong java gắn liền với các servlet API , nếu bạn đã xây dựng ứng dụng web trong java thì hẳn bạn đã rất quen với servlet Servlet mang đến cho bạn một giao thức HTTP rất gần gủi, tất nhiên là yêu cầu rất nhiều mã lập trình trong quá trình phát triển để chuyển đổi các thông tin từ một yêu cầu HTTP Vào năm 2008 một đặc tả mới được gọi là JAX-RS được định nghĩa và hỗ trợ thực thi các dịch vụ RESTful

JAX-RS [1] là một framework mà tập trung vào ứng dụng ánh xạ các ký hiệu java với các đối tượng java rõ ràng Nó có các ký hiệu để ràng buộc các mẫu URI cụ thể và các toán tử HTTP tới các phương thức riêng của lớp java Nó cũng có các ký hiệu ánh xạ tham số mà có thể giúp bạn dễ dàng lấy các thông tin từ yêu cầu HTTP Nó cũng có phần thân thông điệp như reader và writer cho phép bạn tách riêng các định dạng dữ liệu từ các đối tượng dữ liệu java Nó cũng có cơ chế cho phép ánh xạ lỗi với các mã lỗi của HTTP Cuối cùng là nó cũng có các cơ chế phù hợp với sự điều chỉnh nội dung của HTTP

2.2 Sử dụng thư viện JAX-RS

Để tìm hiểu kỹ hơn về cách thức sử dụng thư viện JAX-RS, chúng ta sẽ tìm hiểu qua ví

dụ thông qua một lớp java cụ thể, đó là lớp Customer, class này với đầy đủ các phương thức set, get, các thuộc tính có thể được truy cập thông qua các phương thức set, get này, lớp này được định nghĩa như sau:

Tạo một lớp CustomerResource thực thi dịch vụ JAX-RS

public class Customer {

private int id;

private String firstName;

private String lastName;

…

}

}

CustomerResource là lớp java tường minh, ký hiệu @javax.ws.rs.Path được đặt ở đầu lớp CustomerResource cho ta biết đang sử dụng dịch vụ JAX-RS, lớp java muốn nhận ra dịch

vụ này bắt buộc phải sử dụng ký hiệu như vậy Ký hiệu @Path có một giá trị là /customers, giá trị này cho biết rằng đây là đường dẫn gốc của dịch vụ customers, nếu đường dẫn tuyệt đối của dịch vụ là http://shop.restfully.com thì đường dẫn của dịch vụ sẽ

là http://shop.restfully.com/customers

Trong lớp java chúng ta có thể định nghĩa các phương thức khác nhau, thực hiện các chức năng và công việc khác như kết nới với các lớp java khác hay kết nối cơ sở dữ liệu và sử dụng các tiện ích trong các gói java

2.2.1 Tạo mới một customer

Trong lớp CustomerResource chúng ta sẽ định nghĩa một phương thức để có thể tạo mới một customer như sau:

Một yêu cầu dạng HTTP POST được gửi đến địa chỉ http://shop.restfully.com/customers, phương thức createCustomer() sẽ tiếp nhận yêu cầu này, nó sẽ phân tích yêu cầu và tham

import ;

@Path("/customers")

public class CustomerResource {

private Map<Integer, Customer> customerDB =

new ConcurrentHashMap<Integer, Customer>();

private AtomicInteger idCounter = new AtomicInteger();

@POST

@Consumes("application/xml")

public Response createCustomer(InputStream is) {

Customer customer = readCustomer(is);

customer.setId(idCounter.incrementAndGet());

customerDB.put(customer.getId(), customer);

System.out.println("Created customer " + customer.getId());

return Response.created(URI.create("/customers/"+ customer.getId())).build();

}

số, tạo mới một đối tượng customer rồi ghi vào cơ sở dữ liệu, phương thức này sẽ trả về một mã 201(tạo mới thành công) nếu ghi dữ liệu thành công

Để ràng buộc yêu cầu HTTP POST đối với phương thức createCustomer(), ta sẽ sử dụng

ký hiệu @javax.ws.rs.POST Ký hiệu @Path ta đặt ở ngoài lớp CustomerResource kết hợp với ký hiệu @POST thì tất cả các yêu cầu dạng POST mà được gửi đến URI /customers sẽ do phương thức createCustomer() tiếp nhận và xử lý

Ký hiệu @javax.ws.rs.Consumes trong trường hợp này áp dụng cho phương thức createCustomer() chỉ ra kiểu dữ liệu cần phải tạo để trả lại cho người dùng theo yêu cầu, nếu một kiểu dữ liệu khác, không phải là XML thì một mã lỗi sẽ trả lại cho người dùng

2.2.2 Nhận thông tin customer

Ta sẽ xem xét việc nhận thông tin như thế nào khi có yêu cầu GET /customers/{id}, với {id} là mã customer, hàm nhận thông tin customer được thực thi như sau:

Chúng ta ký hiệu phương thức getCustomer() với ký hiệu @javax.ws.rs.GET để ràng buộc toán tử GET của HTTP với phương thức java này Chúng ta sử dụng thêm ký hiệu

@Path để xác định URI ràng buộc với phương thức này Giá trị của ký hiệu này sẽ được

@GET

@Path("{id}")

@Produces("application/xml")

public StreamingOutput getCustomer(@PathParam("id") int id) {

final Customer customer = customerDB.get(id);

if (customer == null) {

throw new WebApplicationException(

Response.Status.NOT_FOUND);

}

return new StreamingOutput() {

public void write(OutputStream outputStream)

throws IOException, WebApplicationException {

outputCustomer(outputStream, customer);

}

};

}

nối với giá trị của ký hiệu @Path mà chúng ta đã áp dụng đối với lớp CustomerResource, chúng ta cũng sử dụng ký hiệu @javax.ws.rs.Produces đối với phương thức getCustomer() để chỉ cho JAX-RS biết kiểu dữ liệu trả về cho máy khách là application/xml

GetCustomer() nhận một đối số id, đối số này xác định customer mà máy khách yêu cầu, chúng ta sử dụng id này để truy vấn trong cơ sở dữ liệu Ký hiệu

@javax.ws.rs.PathParam sẽ thông báo cho JAX-RS biết rằng tham số id được truyền từ URI vào và giá trị của nó phải phù hợp với giá trị khai báo sau @PathParam, trong trường hợp này tham số {id} được lấy từ /customers/{id} Ví dụ nếu URI yêu cầu GET đến là http://shop.restfully.com/customers/333, thì giá trị xâu 333sẽ được cắt ra từ URI, chuyển nó thành kiểu số rồi gán nó vào giá trị id của phương thức getCustomer()

2.2.3 Cập nhật customer

Khi máy khách gửi yêu cầu PUT /customers/{id} thì có nghĩa là máy khách muốn cập nhật khách hàng có mã là {id}, chúng ta sẽ cài đặt phương thức cập nhật khách hàng như sau:

Trong phương thức updateCustomer() chúng ta sử dụng ký hiệu @javax.ws.rs.PUT để ràng buộc yêu cầu HTTP PUT với phương thức này Cũng giống như phương thức getCustomer() thì updateCustomer() cũng sử dụng ký hiệu @Path nối với tham số {id}

mà có thể phù hợp với URI /customers/{id} Cũng giống như getCustomer() chúng ta sử dụng ký hiệu @PathParam để cắt id từ URI yêu cầu đến và một tham số thứ hai cho phép đọc XML

@PUT

@Path("{id}")

@Consumes("application/xml")

public void updateCustomer(@PathParam("id") int id,InputStream is) {

Customer update = readCustomer(is);

Customer current = customerDB.get(id);

…

}

2.3 Các toán tử HTTP và ánh xạ URI

Trong phần trên chúng ta vừa mới sử dụng các ký hiệu @GET, @PUT, @POST, và

@DELETE để ràng buộc với các phương thức java với các toán tử của HTTP Chúng ta cũng đã sử dụng ký hiệu @Path để ràng buộc với các phân đoạn của URI tới các phương thức java, các ký hiệu cơ bản này chúng ta đã áp dụng một cách rõ ràng, tường minh, tuy nhiên vẫn còn nhiều ký hiệu khác phức tạp hơn và sẽ tìm hiểu chi tiết hơn các ký hiệu đó trong phần này

2.3.1 Các toán tử ràng buộc của HTTP

JAX-RS định nghĩa 5 ký hiệu cơ bản dùng để ánh xạ đặc biệt với các toán tử HTTP:

ở đây chúng ta có một phương thức đơn giản là getAllCustomers() Ký hiệu @GET chỉ thị cho JAX-RS biết rằng phương thức java này sẽ xử lý các yêu cầu của HTTP GET tới URI /customers Một trong năm ký hiệu khác sẽ được sử dụng để ràng buộc với các toán

tử HTTP khác Chú ý một điều rằng ta chỉ có thế áp dụng mỗi ký hiệu HTTP cho mỗi phương thức java Một mã lỗi sẽ được trả lại nếu ứng dụng nhiều hơn một ký hiệu

2.3.2 Ký hiệu @Path và tùy chọn mở rộng

Với ký hiệu @Path thì có nhiều hơn, tùy chọn phức tạp hơn, @Path có các mô tả phức tạp hơn mức cơ bản mà cho phép bạn xác định các yêu cầu ràng buộc khác trong URI,

@Path cũng có thể được dùng ở đầu phương thức java để phân chia luồng yêu cầu tài nguyên con của ứng dụng

Ký hiệu @Path được định nghĩa trong JAX-RS để xác định các tham số phù hợp trong URI đến của yêu cầu HTTP Ký hiệu này có thể được đặt ngay đầu lớp java hoặc một nơi bất kỳ nào trong lớp đó Ví dụ với một lớp java đủ điều kiện để nhận yêu cầu HTTP thì lớp đó phải có ít nhất một mô tả @Path(“/”), các lớp kiểu này được gọi là tài nguyên gốc Giá trị của ký hiệu có thể là một biểu thức mà mô tả URI liên quan đến nội dung gốc của ứng dụng Để nhận một yêu cầu, lớp java phải có ít nhất một ký hiệu mà HTTP cần nhận

ra được áp dụng là @GET mà không yêu cầu ký hiệu @Path, ví dụ:

Một yêu cầu HTTP GET tới /orders và phân bổ tới phương thức getAllOrders(), @Path cũng có thể được áp dụng trong lớp java, giá trị sẽ kết hợp với giá trị @Path ở ngoài lớp

Bởi vậy trong trường hợp như trên thì tài nguyên được xác định thông qua hàm getUnpaidOrders() với địa chỉ /orders/unpaid

2.4 Ánh xạ JAX-RS

JAX-RS định nghĩa rất nhiều ký hiệu để có thể lấy thông tin từ yêu cầu HTTP và ánh xạ

nó vào các phương thức java Điều mà chúng ta quan tâm đó là các tham số trong URI đến, cũng có thể là các giá trị xâu truy vấn trong URI Máy khách cũng có thể gửi các mã HTTP trong giá trị header hoặc giá trị cookie mà dịch vụ cần xử lý các yêu cầu JAX-RS cho phép bạn nắm bắt các thông tin này khi bạn cần nó thông qua các ký hiệu ánh xạ và APIs

2.4.1 Các ký hiệu ánh xạ lấy thông tin cơ bản

 @javax.ws.rs.PathParam: ký hiệu này cho phép bạn trích lọc các giá trị từ các tham số tạm đưa vào từ URI

 @javax.ws.rs.QueryParam: ký hiệu này cho phép bạn trích lọc các giá trị từ các tham số truy vấn vào từ URI

 @javax.ws.rs.FormParam: ký hiệu này cho phép bạn trích lọc các giá trị từ dữ liệu trên form gửi vào

 @javax.ws.rs.MatrixParam: ký hiệu này cho phép bạn trích lọc các giá trị từ các tham số dạng ma trận vào từ URI

 @javax.ws.rs.HeaderParam: ký hiệu này cho phép bạn trích lọc các giá trị từ phần header của yêu cầu HTTP

 @javax.ws.rs.CookieParam: ký hiệu này cho phép bạn trích lọc các giá trị từ cookie của HTTP được gửi bởi máy khách

Các ký hiệu này thường được sử dụng trong các tham số của phương thức truy cập tài nguyên Khi JAX-RS nhận yêu cầu HTTP nó sẽ tìm ra phương thức java mà phục vụ yêu cầu này Nếu phương thức java có tham số thì chúng sẽ được khai báo ngay phía sau các

ký hiệu tương ứng, từ đó các ký hiệu này sẽ có nhiệm vụ trích lọc thông tin từ HTTP ánh

xạ vào các tham số thực để cho các phương thức java sử dụng

Đối với mỗi yêu cầu tài nguyên, ta có thể sử dụng các ký hiệu ánh xạ này vào các trường

dữ liệu hoặc các phương thức setter, thậm chí là ở các tham số của hàm constructor

2.4.2 @PathParam

Trong ví dụ trên hướng yêu cầu tài nguyên của HTTP theo URI /customers/{id}, phương thức getCustomer() sẽ trích lọc mã ID từ URI bằng cách sử dụng @PathParam, giá trị của

ký hiệu @PathParam là “id” trùng với tham số trong đường dẫn là {id}, đó cũng là tham

số mà ta định nghĩa trong @Path của phương thức getCustomer()

{id} là một xâu mô tả trong yêu cầu URI, JAX-RS sẽ tự động chuyển sang giá trị nguyên trước khi phương thức getCustomer() sử dụng Nếu các tham số string đường dẫn URI không thể chuyển đổi thành kiểu nguyên được thì lúc đó một mã lỗi sẽ được trả về cho máy khách từ máy chủ

Bạn cũng có thể truyền nhiều tham số vào đường dẫn URI vào trong lớp java của bạn, ví

dụ chúng ta sẽ sử dụng firstname và lastname để xác định customer ở trong lớp CustomerResource:

Ở đây chúng ta có các tham số trong URI là {first} và {last}, nếu máy khách yêu cầu một HTTP là GET /customers/bill-burke, thì bill sẽ được ánh xạ vào tham số firstname còn burke sẽ được ánh xạ vào tham số lastname

Đôi khi các tên tham số trong URI sẽ được lặp đi lặp lại trong các biểu thức của @Path, các tham số này được truyền đầy đủ vào từ URI, tham số trước có thể bị thay thế bởi tham số sau, xác định mục tài nguyên con Trong trường hợp đó ký hiệu @PathParam luôn luôn tham chiếu đến tham số cuối cùng, ví dụ:

Từ ví dụ trên ta thấy nếu yêu cầu là GET /customers/123/address/456 thì tham số addressId trong phương thức getAddress() sẽ có giá trị là 456

public StreamingOutput getCustomer(@PathParam("first") String firstName,

@PathParam("last") String lastName) {

2.4.3 @QueryParam

@javax.ws.rs.QueryParam cho phép bạn ánh xạ các biến dạng truy vấn riêng tới các tham

số java của bạn Chẳng hạn chúng ta muốn truy vấn customer từ cơ sở dữ liệu và nhận một tập con các customer từ cơ sở dữ liệu, lúc đó URI truy vấn có dạng:

GET /customers?start=0&size=10

Tham số start là chỉ số bắt đầu mà ta muốn truy vấn từ cơ sở dữ liệu và size là số lượng customer mà ta muốn nhận Khi đó dịch vụ JAX-RS sẽ được thực thi như sau:

Ở đây chúng ta sử dụng ký hiệu @QueryParam để ánh xạ vào các tham số trong URI là

“start” và “size” vào các tham số java là start và size, các tham số này JAX-RS sẽ tự động chuyển đổi từ dạng xâu thành kiểu nguyên

Đôi khi ta cũng cần lấy tham số theo kiểu mảng, tức là duyệt qua một danh sách tham số rồi lựa chọn những tham số mình cần, interface javax.ws.rs.core.UriInfo cho phép bạn làm điều đó, trong interface này có phương thức getQueryParameters() cho phép bạn lấy toàn bộ các tham số trong URI dạng truy vấn đến:

@Path("/customers")

public class CustomerResource {

@GET

@Produces("application/xml")

public String getCustomers(@QueryParam("start") int start,

@QueryParam("size") int size) {

}

}

public interface UriInfo {

public MultivaluedMap<String, String> getQueryParameters();

public MultivaluedMap<String, String> getQueryParameters(boolean decode);

}

Bạn có thể ánh xạ thể hiện UriInfo sử dụng ký hiệu @javax.ws.rs.core.Context Sau đây

là ví vụ về việc sử dụng lớp này để ánh xạ và ký hiệu @Context để nhận một số tham số cần thiết trong URI đến:

2.4.4 @FormParam

Ký hiệu @javax.ws.rs.FormParam được sử dụng để truy cập dạng form www-formurlencoded Hay nói cách khác nó được sử dụng để truy cập các mục nhập liệu được chuyển tới bởi tài liệu form HTML Ví dụ chúng ta thiết lập một form nhập liệu một khách hàng mới trên website của chúng ta như sau:

application/x-Và chúng ta đẩy dữ liệu trực tiếp form này đến dịch vụ JAX-RS được mô tả như sau:

@Path("/customers")

public class CustomerResource {

@GET

@Produces("application/xml")

public String getCustomers(@Context UriInfo info) {

String start = info.getQueryParameters().getFirst("start");

String size = info.getQueryParameters().getFirst("size");

First name: <INPUT type="text" name="firstname"><BR>

Last name: <INPUT type="text" name="lastname"><BR>

<INPUT type="submit" value="Send">

</P>

</FORM>

Như vậy ở ví dụ trên chúng ta đã ánh xạ firstname và lastname từ form nhập liệu tới các tham số trong hàm java là first và last Form dữ liệu khi đến dịch vụ JAX-RS là một dạng URL-encoded Khi sử dụng @FormParam, JAX-RS sẽ tự động giải mã các giá trị từ form

và ánh xạ vào các tham số tương ứng

@Path("/customers")

public class CustomerResource {

@POST

public void createCustomer(@FormParam("firstname") String first,

@FormParam("lastname") String last) {

Chương 3: Bảo mật với dịch vụ RESTful

Chương này sẽ bàn về vấn đề bảo mật với dịch vụ RESTful, các phương pháp bảo mật cơ bản, cũng như các vấn đề về caching và scale Từ đó áp dụng cơ chế bảo mật xác nhận, cấp phép và mã hóa

3.1 Giới thiệu

Dịch vụ web theo kiến trúc REST đang trở nên phổ biến qua nhiều ứng dụng gắn liền với các dịch vụ dễ dàng cho sự phát triển Dịch vụ dựa vào các toán tử chuẩn của HTTP như GET, POST, PUT và DELETE, kết quả trả về của dịch vụ phụ thuộc vào ứng dụng, có thể là XML, JSON, TEXT hoặc định dạng khác

Phương pháp phổ biến hiện tại cho việc bảo mật bao gồm xác thực người dùng và bảo mật tầng vận chuyển về việc bảo mật phiên làm việc qua mạng, đây là cơ chế bảo mật các URL qua mạng bằng cách xác nhận cho các máy chủ, tuy nhiên nhược điểm của cơ chế này là dựa vào sự hiểu biết về liên kết và xác nhận của người dùng, cũng dựa vào nhược điểm này mà vấn đề lừa đảo đã xảy ra qua mạng Cookies của web được sử dụng để truyền thông tin và thực hiện các thông tin bảo mật trong yêu cầu HTTP trong suốt phiên làm việc Dữ liệu cá nhân người dùng thường được lưu trữ hoặc truyền qua mạng mà không mã hóa, hơn nữa người dùng khó có thể kiểm soát, hoặc kiểm soát yếu các thông tin cá nhân truyền qua các dịch vụ, khi đó người xấu có thể truy cập thông tin cá nhân của người dùng và lan truyền nó qua mạng thì thông tin đó khó có thể mà kiểm soat tốt được Cách bảo vệ duy nhất có thể là bảo mật URL, hoặc có thể truyền các thông tin đã được

mã hóa, đề phòng trong trường hợp thông tin bị đánh cắp bởi người khác, thực tế người dùng có thế tự bảo vệ được các thông tin của mình

Có nhiều cách để thiết kế và thực thi ứng dụng web, nhiều ứng dụng được thực thi bởi

mô hình triệu gọi thủ tục từ xa (RPC) qua HTTP, đó là mô hình thực hiện chủ yếu ở phía máy chủ, điều này làm tăng tải trọng của máy chủ và điều này cũng không giúp được các nhà cung cấp dịch vụ dễ dàng mở rộng được các dịch vụ của họ khi số lượng máy trạm kết nối cao Đây là một trong các vấn đề rất quan trọng cho các ứng dụng web ngày nay Một trong các mô hình có thể đáp ứng được vấn đề này đó chính là REST và nó đã trở thành một phần quan trọng cho các yêu cầu của nhà thiết kế và phát triển ứng dụng web, REST mang đến sự rõ ràng trong thiết kế các ứng dụng web có khả năng mở rộng, chẳng hạn nó cho phép máy chủ có thể là phi trạng thái hoặc ứng dụng lợi ích của việc lưu giữ nhiều URI tĩnh Trong kiểu kiến trúc REST URI có thể được tham chiếu đến sau phiên làm việc, đây cũng là điều mà các mô hình ứng dụng khác khó có thể đạt được

Tuy nhiên vẫn có khoảng cách giữa kiến trúc web và các tính năng bảo mật hiện tại, cơ chế bảo mật của web ngày nay không phù hợp với kiến trúc REST trong trường hợp các phiên làm việc bảo mật tạo ra các phiên làm việc với các khóa xác định nhưng nhiều dữ liệu tĩnh được lưu trữ trong bộ đệm web không được bảo vệ và lấy dữ liệu đồng thời từ

bộ đệm web được Điều này làm giảm khả năng mở rộng của kiến trúc REST cho các ứng dụng và dịch vụ yêu cầu điều khiển truy cập tới dữ liệu

3.2 Kiểu kiến trúc REST phù hợp với bộ đệm web

Phiên bản HTTP 1.1 có bốn phương thức chính cho các yêu cầu của máy trạm được đặt tên là GET, PUT, POST và DELETE( ngoài ra còn có các phương thức khác như HEAH, CONNECT hoặc TRACE tuy nhiên chúng ta không bàn luận các phương thức này ở đây) REST điều khiển tất cả các URI và các phương thức HTTP áp dụng với chúng Nói một cách tổng quát hơn thì GET được xem như là hành động để đọc dữ liệu, PUT là hành động cập nhật dữ liệu, POST là hành động tạo mới dữ liệu và DELETE là hành động xóa

dữ liệu, GET (cũng như HEAD) được xem là hành động an toàn vì nó không làm thay đổi dữ liệu nhưng các hành động còn lại nói một cách nào đó thì chúng làm thay đổi dữ liệu

Lưu trữ nội dung của web cần gắn liền với các URI, các URI này được gán với các mục

dữ liệu là một phần quan trọng của RESTful và ứng dụng phương thức HTTP GET Dữ liệu cần phải được chuyển đến người dùng thông qua trình duyệt web và được lấy từ máy chủ web qua thao tác HTTP GET Giữa máy trạm và máy chủ có thể có web proxy và bộ đệm web chứa các yêu cầu URI được hiện thị trong yêu cầu GET Bộ đệm làm giảm băng thông sử dụng, và đặc biệt là giảm tải cho máy chủ, hiển thị tốt nhất đến người dùng

Có nhiều mô hình bộ đệm web được thực thi trong trình duyệt web và chính trong các máy trạm của chúng, như bộ đệm proxy(cái này yêu cầu cấu hình trong trình duyệt web), tất nhiên cũng có giao thức để quản lý nội dung của bộ đệm web như ICP(Internet Cache Protocol), HTCP (Hypertext Caching Protocol) Hơn nữa bộ đệm web có thể kết hợp làm việc cùng với nhau, điều này rất quan trọng khi khả năng mở rộng của dữ liệu phụ thuộc vào các dịch vụ Giao thức HTTP có cơ chế để có thể điều khiển được bộ đệm cho phép

bộ đệm cung cấp kết quả đến máy trạm mà không cần kiểm tra lại thông tin từ máy chủ

Cơ chế xác nhận được sử dụng trong bộ đệm để kiểm tra từ máy chủ thời gian quá hạn trong bộ đệm Sau đó một tính năng quan trọng của mô hình kiến trúc RESTful đó là bộ đệm trở nên không hợp lệ Điều này luôn xảy ra với các yêu cầu HTTP PUT/ POST/ DELETE được ứng dụng cho các URI tương ứng Từ khi những yêu cầu thay đổi URI tương ứng bộ đệm có thể không thay đổi phiên bản tương ứng trả lại cho khách hàng

nếu HTTP GET được thiết kế để sử dụng như là một phương thức triệu gọi từ xa cho việc ghi dữ liệu thì bộ nhớ đệm sẽ xem như là đã có một kết quả trong đó cho URI và trả lại kết quả cũ Điều này hoàn toàn đúng cho ứng dụng và dịch vụ logic Kiểu kiến trúc REST thực thi ứng dụng web đưa ra sự hướng dẫn tốt cho người thiết kế và phát triển Nó được hiểu như sự tự nhiên của web tuy nhiên không lạm dụng chúng Nó cũng khuyến khích việc sự dụng kịch bản cho tất cả phiên người dùng xử lý dữ liệu cụ thể như là nội dung dựa vào kết quả theo kịch bản không lưu trữ đệm

3.3 Khóa mã hóa nội dung đối xứng

Ứng dụng web trong kiểu kiến trúc REST tạo ra các URI theo cách mà các video hoặc hình ảnh có thể dễ dàng được lưu bộ đệm vì lý do mở rộng Nhưng với công nghệ web hiện tại nếu chúng ta lưu bộ đệm, bất kỳ ai cũng có thể truy cập được dữ liệu nếu biết cụ thể URI của dữ liệu đó, khi mà URI đó không được bảo mật Vấn đề là nếu ta áp dụng các phiên làm việc bảo mật với TLS và chuyển tất cả các dữ liệu vào một kênh bảo mật riêng thì vấn đề bộ nhớ đệm xem như không còn hiểu quả Ngoài ra dữ liệu được mã hóa nhiều lần cho mỗi lần máy trạm truy cập dữ liệu, sinh ra dư thừa mã hóa Nhưng bù lại thì

dữ liệu được an toàn và phiên làm việc của người dùng được bảo mật Một giải pháp có thể để cải thiện vấn đề này là vô hiệu hóa bộ nhớ đệm chung và áp dụng các ứng dụng xác định bộ nhớ đệm gần máy chủ nơi các phiên làm việc bảo mật kết thúc Tuy nhiên đây cũng không phải là một giải pháp tốt khi nó yêu cầu nền ứng dụng xác định bộ nhớ đệm và không sử dụng các lợi ích của bộ nhớ đệm proxy Nó cũng yêu cầu máy chủ mã hóa dữ liệu khi truyền qua các đường truyền riêng, điều này cũng sinh ra dư thừa mã hóa, yêu cầu bảo mật dữ liệu trong máy chủ sau khi kiểm soát truy cập

Hình ảnh là loại dữ liệu mà trong cộng đồng người sử dụng có thể chia sẽ nhiều nhất, tuy nhiên là chia sẽ cho những đối tượng đáng tin cậy, vì vậy hình ảnh cần phải được bảo mật Ngoài ra, các trang web thương mại yêu cầu người dùng phải trả phí cho nội dung

mà họ muốn xem và hạn chế nội dung tới khách hàng mà đã trả, tuy nhiên cùng thời điểm

họ muốn kiến trúc của họ mở rộng nhất có thể và cho phép lượng người dùng lớn nhất có thể Vì vậy có một chút mâu thuận giữa hai mục tiêu sử dụng bộ nhớ đệm và mã hóa nội dung

Vấn đề này sẽ được giải quyết một cách đơn giản, chúng ta sẽ tạo một khóa bảo mật nội dung Tùy chọn gắn thời gian sống của khóa đó với thời gian của bộ nhớ đệm của URI và cung cấp khóa này cho các khánh hàng được phép truy cập nội dung Tất cả dữ liệu được

mã hóa với khóa bảo mật nội dung, sau đó được lưu giữ phía ngoài dịch vụ Chúng ta yêu cầu xác thực người dùng và quyết định ủy quyền truy cập nội dung(chẳng hạn như thông qua TLS hoặc chứng thực HTTP và cơ chế cấp quyền) Dữ liệu thực tế sau đó được truy