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

«_ Tiến hành cải đặt API RESTinl theo phương pháp rên © Cho thay ring APT vim cai dil có thé ding chung cho cã người và máy, Bố cục luận văn Chương ¡: Giới thiệu chung vẻ địch vu web, k

ĐẠI HỌC QUOC GIA HA NOI 'TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYÊN THÁI SƠN

TIM HIEU DICH VU WEB RESTful VA UNG DỤNG

TRONG XAY DUNG HE THONG SMSGATEWAY

LUAN VAN THAC Si CONG NGHE THONG TIN

Ha Noi — 2014

DẠI TỌC QUỐC GIA TIA NOI

TRUONG DAL HQC CONG NGHE

NGUYÊN THÁI SƠN

TÌM HIẾU DICH VU WEB RESTful VA UNG DUNG TRONG XAY DUNG HE THONG 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 NGIIE THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: T8 Võ Đình Hiểu

Hà Nội - 2014

LỜI CẮM ƠN

‘Trude tiên tôi xí chân thánh cám on TS.V6 Dinh 1iểu, người đã tận tỉnh hưởng

cẩ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 thay cô giáa 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, quau lãm, động viên trong suốt thời gian Lôi họơ tập và nghiên cửa 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

KI6CNPMR, 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 hữu ích trang suết thời gian học

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 uận văn tốt nghiệp vừa qua

T1à Nội, tháng 07 năm 2014

Tac gid luận văn

Nguyễn Thái Sơn

LOL CAM DOAN

Tỏi xin cam doan bản luận văn “Tim hide dich vu web RESTful và ứng dụng trong xây đựng hệ thông SMSGufeway” là công trình nghiên cứu của tôi dưới sự hướng,

dân khoa hoc của T§.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 dụng 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

da Nội, tháng 07 nằm 2014

Tác giả luận van

Nguyễn Thái Sơn

L7 Dich va web RESTA

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

2.1 Giới thiện - - - 22

3.2.2 Nhận thông tin customer

2.2.3 Cp nhdt customer

3.5 Kết luận

3.6 Ap dang bao mat dich va web RESTfal

3.6.1 Bão mật địch vụ web RESTâul bằng cách cấu hình web.xuÚ - 40

3.6.2 Rao mit dich va web RESTful bing cach sit dung SecurityContext ~ 41

Chương 4 Thiết kế và biện thục hệ thắng SMSGateway

42 Nguyễn Hắc hoạt động - - - - 45

4.12.5 Xóa MO bằng thau lác DHLETE

Danh mục các ký hiệu và chữ viết tắt

REST: Representational State Trans[er(Chuyển dối trạng thái dại điện)

MO: Mobile Originated(Tin nhắn đến)

MT: Mobile Terminated (Tin nhan di)

SMS: Short Message Service (Tin nhin)

XML: Extensible Markup Langguage (Ngôn ngữ đánh dau mé réng)

SOAP: Siiuple ObjeeL Aceess Protocol (Giao thức truy cập dối tượng đơn giản)

WSDL: Web Service Description Langguage (Ngôn ngữ mô tà địch vụ)

UDDI: Universal Description, Discovery va Integration

IITTP: Lypertext Transfer Protocol (Giao thite truyén tai nội đưng siếu văn bản)

W3C: World Wide Web Consortium (Té chite World Wide Web)

RPC: Remote Proeedure Call (Triệu gọi thú tục tử xa)

JAX-RS: Java APT far RESTful Web Services (Thu vién APT cho dich va web RESTful) URL: Uniform resource identifier (Nae định tai nguyén déng nhat)

APL: Application programming interface (Giao diện lập trình ứng dụng)

MỞ BẦU

Các hệ thẳng dựa trên dịch vụ web ngày nay

TIệ thống đựa trên nên web là hệ thông mà cho phép những ứng dụng hoặc địch vụ đang

cư trú trên một máy chủ có thế được truy cập bằng cách sử đụng một trình đuyệt web nảo

¡ thông qua web [8] Đó là một hệ

thống bao gồm một tập hợp các lỗ chức phức tạp và chặt chế như thị rường, địch vụ, các

đó và cá thế truy cặp từ bắt cứ nơi nào trên thể g

giao địch liên kết với nhau Giao dich được hiểu là sự kiên heặc khi tạo tiến trình hoặc

mội người dùng hay chương trình máy tính nào đỏ yêu cẩu, và mỗi giáo địch đồ được coi

Tà một một đơn vị công việc duy nhất cân phải phát hưu ruột bản ghỉ log vào đữ Hệu hệ

thống, trong hoàn cảnh nảy mỗi giao dịch dược xác định là một dơn vị duy nhất và kết

thúc một Irong Hai trường hợp là thánh công hoặc không (hành công Hơn nữa mỗi giao

dịch bắt buộc phải dược ghi lop lại cho di nó thành công hay that bai dé hé thống biết dược rằng dã 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

tan tại 100%, có thể xử lý số lượng lớn các giao địch và sử dung 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 đựa trên nẻn web sử đụ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 AP cho con người giao tiếp với

may tinh Diéu nay thé hiện một vẫn đề thực tẻ răng trong nhiều trường hợp các dich 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 tri nang cắp hệ thống Hen nữa các ADI nảy vẫn có nhược

điểm

Nhiều cuộc diễu tra vẻ một loại kiến trúc có tên là REST [7.15] da được thực hiện và kết

qua cho thầy RHST 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 dua đến kết luận dễ thiết kế web service theo kiến trúc REST như sau:

» Higu được các nguyên tắc cửa REST,

«©- Hiểu được loại đữ hiệu được điều khiến bối các hệ thông dua trén nén web.

Bua ra duoc phuong 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 RESTinl theo phương pháp rên

©) Cho thay ring APT vim cai dil có thé ding chung cho cã người và máy,

Bố cục luận văn

Chương ¡: Giới thiệu chung vẻ địch vu web, kién tric va các thành phân cơ bản của địch

vụ web như XML, SOAP, WSDL và UDDI từ đó đua ra mục tiêu phát triển hiện văn, cũng trong chương này sẽ giới thiệu về REST, mô tả tir khéa REST ngay nay rat phi hop

với nên tảng cơ bản với dịch vụ web, đưa ra lý đo tại sao chọn REST để phát triển địch

vu web, và phân giới thiệu hệ thống mà sau này tác giả có ý định phát triển dich va RESTiul cũng được giới thiệu trong phan này

Chương 2: Giới thiệu thư viện JAK-RS va 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ử dủa thư viện JAX-R5 cũng sẽ dược

trình bay ở chương nảy

Chương 3: Chương này giới thiệu ác phương pháp bảo mật cơ bản cũng như cách thực

hiện và áp dung 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 chỉ 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 cia REST va str dung thư viện JAX-RS đề thiết kế các đị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ế thiy duoc REST API phan 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 cođc mô tả các tiễn trình phát triển ứng, dụng va cung cấp một một vải tool để có thể kiểm clhứng ứng dụng thực hiện các yêu cầu

REST API.

Chương 1: Dịch vụ Wcb và REST

Chương này sẽ giới thiệu tổng quan về địch vụ web, kiến trúc, thành phản cơ bán, cũng

trong chương nay ching ta sé tim hiểu nguồn gốc từ RUST 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ơ

ban cia REST, các đặc điểm chính và lý do tại sao chúng ta lai st dung REST

Người đàng hoặc máy tính thực hiện trong tác với địch vụ web thông qua giao thức SOAP (Simple Obieot Access Protocol) [I0] Dây là một trong các giao thức được sử

dung để 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

hư 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 đụng một cách 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 lất cả đã cả được quy về một

định dạng chứng Ngoài ra bản chất của dịch vụ web là một lập hợp các đối lượng, các

phương thúc dược thực thị và công bố lên mạng dễ cỏ thể triệu gọi được lừ xu thông qua các ứng dụng khảo nhau

1.2 Kiến trúc vả các thành phần của dịch vụ Web

Công nghệ đị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 dung

dua trên nên web sử dụng các chuẩn mỏ như XML, SOAP, WSDL, UDDI [8] Trong đó

XML được sử đụng để mê tả dữ liệu, SOAP đóng vai trỏ giao thức truyền tải dữ liệu,

WSDL déng vai trò mô tâ cho địch vụ web còn UDDT đóng vai trò cung cấp đanh sách

các địch vụ web đang hoạt động Chỉ tiết về các chuấn mở này chúng ta sẽ bản chỉ tiết trong phan sau, phan các thành phần cơ bản của địch vụ web

Tương tác dịch vụ sử lũng SOẠP

Hình 1.1: Mô hình kiên trúc dịch vụ web

1.2.1XML

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 cai đặ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

© M6 ta cae giao thie sit dung trong dich vu web

1.2.2 SOAP

SOAP (Simple Object Aceess 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

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 thí 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 ti 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 digp SOAP

như hình sau:

Hình 1.2: Cầu trúc của một thông điệp SOAP

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 vu web Ban đâu WSDL được Microsoft và Ariba dé xuat,

nhưng hiện nay WSDL được quản lý và phát triển bởi W3C Mỗi một dic ta 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.3:Câu trúc của WSDL

Một đặc tả WSDL bao gồm 2 phan chỉnh: phân trừu tượng (Abstract defmitions) vả phan

eụ thể (Concrete deinitions), phân trừu tượng bao gồm các thông tin được chửa trong các

thé types, message va portypes Phan cụ thể bao gồm các thông tin được chứa trong các

thé bindings va ports Méi thành phan sẽ cỏ một tham chiêu đến một thành phản khác

được mồ tả như hình sau:

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: 14 mét thanh phần trừu tượng mỏ tả cách thức giao tiếp giữa máy khách

UDDI (Universal Description, Discovery và Tntepration) cũng được Microsoft, TBM 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 (OrgamzaHitan for the Advancement of Structured Information Standards) UDDT

được xây đựng nhằm mục đính cúng cap khả răng cho phép công bố, tổng hop va tim kiếm các địch vụ web UDDI đưa ra một lập hợp các hàm APT được chịa làm 2 phân

Inquiry APT, ding dé tim kiểm vẻ truy xuất cáo địch vụ web đã ding ky va Publisher ‘s

API, ding dé công bổ các dich vụ web muốn dăng ký Thông tin tổ chức trong UDDI dược chia làm 3 phần

«White pagos: liệt kê thông lin của các nhà cùng cấp dịch vụ web, hao gdm dia chi,

thông Im liên lạc và đmh danh

Yellow pages: phân loại địch vụ theo tổ chức hay nhóm dịch vụ hoặc địa điểm đặt

cáo dịch vụ

* Green pages: cung cdp thong lin vé cae địch vụ web, cách thức truy cập cũng như

tương tác với các địch vụ web đó,

11

chương trình trên máy lính

Mặc dù web là công cụ giao tiếp giữa con người với con người, sau dó dược tiên hóa một cách tĩnh 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 dang truyền thông phức tạp giữa máy tính vả máy tỉnh

1ITML 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 ITTMIL về việc giao

tiếp giữa các chương trình

XML duoc truyền giữa các máy tính sử dung giao thức HTTP thông qua RPC, str dung

HTTT 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

âu XML-RDC luôn luôn có một trã lời KML-RPC tương ứng, bởi vì yêu cầu và tr

đu phải xây ra trên cùng môi 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 Irường hợp chủ phí để tạo ra hệ thông đó là điều không

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

12

* Mét yéu cau XML-RPC bao gdm hành động dễ 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 dap ứng yêu cầu

và trả lời yêu cầu

+ Một APIXML-RPC thì cần phải định nghĩa mã lỗi riêng của né, khi đỏ sẽ dễ đàng

sử địmg trạng thái mã lễi hơn

«_ Với kiểu API sử đụng XML-RPC thì các chức năng về xác thực và cache bên phía may 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ụ RBSTfuL Chúng ta sẽ tìm hiểu dịch vụ này chỉ tiết hon trong

chương 2 và chương 3 để có thế hiểu REST được thay thế XMT.„RPC phir thé nao

1.4 REST la gi?

REST (Representational State Transfer) 14 mét kiéu kiến trúc dược định nghĩa bởi Roy Vielding [6] Muc dinh ctia REST là thiết kế các ứng dựng mạng phân tản sử dụng LLEP như là một giao thức tầng ung 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 eda REST

Như ruột hệ quả lấ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 RESTIul đã được đưa ra như là một giải pháp để thay thể việc thực hiên triệu gọi từr

xa (RPC) thông qua wcb

Web đựa vào tài nguyên, nhưng các địch vụ web lớn lại không đựa vào tài nguyên Web dựa vào LIRT và liên kết nhưng các địch vụ web lớn lại không dụa vào chúng Web dua vào 1TTTP và các tinh năng của nó, nhưng các địch vụ web hau như không đựa vào bắt

kỳ tính năng nao cla HTTP Vân để này không phải là các địch vụ web lớn không nhận

ra mà nỗ cảm thấy không nhận được lợi ích gi ur đị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 điên đồng nhất Chúng không được rõ rằng, hiểu được một van dé không giúp mình tiểu được van để tiếp theo, trong thực tế chúng cũng có van để khi tương tác với nhiều

khách hàng cing mét hic

RHSF là một kiểu kiến trúc cho hệ thống phản tán nhu World Wide Web 16 thie thi kién tric RESTful ta cần phải tuân thủ theo hướng dẫn của ROA, kiến trúc hướng tai nguyên, trong tải liệu này sẽ có các quy tắc cho phép ta thiết kế địch vụ R1281ful [6]

13

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,

đỏ la Tai nguyên(Resources), Khả năng đánh địa chi(Addressability), Phi trang

thái(Statelessness), Kết nói(Comnectedness), Giao diện đồng nhat(Uniform Interface) và

Khả năng lưu cache(Cacheability),

1.8.1 Tài nguyên

Mọi thử mà đị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ử,y.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 hữp/serverlast version vả một URI xác địh một tải nguyên khác hftp:/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 ƯRI này sẽ trổ vào bai tài nguyên khác nhau

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ó đủ ƯRI đẻ đá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 6 may khách,

sau lần truy cập đầu tién thi tai 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 g6, ta thay URI cia 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à đị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 ma vẫn xem được đúng hình ảnh ban d6 ma minh dang 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à

1.5.3 Phi trang thai

Mọi yêu cau HTTP déu hoan thanh 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 thi 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 thi 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 nay lam 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 may 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 cau ma may khách đã gửi, điều này có nghĩa là máy chủ web được

thay thể một cách dé dang 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 thi hệ thông sẽ trở nên đơn giản hơn đề thực hiện 1.5.4 Kết nối

Dich vu 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 điện có thể là siêu âm thanh,

co the la tai 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

Phương thức GBT có nghĩa là nhận bât kỳ thông tm gì, trong lường hợp thông tìm đữ hiệu

1à đạ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 thi thông lin mày được xác định bằng một TRT là đại điện của một lài

nguyên

GL 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 tm 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 ITTTP 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 GIIT

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 lài nguyên được trả về thì thông ché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 vị, đ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 mang

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 đữ 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 đữ 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 dịnh bởi URI, trang thai trả về nến thành công là 200 (thành công) Nếu lạo tài nguyên mới thì trạng thái

17

tra vé 14 201 (tao tai 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 ngưyên mới ở phần header của thơng tin

HTTP PUT

Phương thức PL;T yêu câu thực thẻ định kèm được cung cấp theo củng yêu cầu URL

Nếu URI tham chiều tới tài nguyên đã tổn lạ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 lại thì cĩ khả năng URI dĩ 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 lãi nguyên mmớ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 doi tải nguyên thi trạng thái trả về là 200 Nếu

¡ nguyên mới khơng được tạo, cfng khơng thay đổi lai

nguyễn cũ thi một trạng thải mã lỗi sẽ dượ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, trang 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 TD của tải nguyên trong URT đĩ),

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 PỨT là một phương thức khơng thay đổi (giếng rửuz

GET) nhưng POST thì ngược lại

thì một trạng thái ¡nã lỗi lương ứng sẽ được Irả về một cách phù hợp,

1.8.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

khộng thời gian nào do Co ché cache thi lam 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 co ché cache trong LITTP đĩ chính lả thời hạn và xĩc thực Theo RIFC2616 [2] thì mục tiêu của cache trang IITTP/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

18

thông trên máy chủ, nền các yên câu cũ thi 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

Thời hạn & header chi cha bạn biết ngày giờ tải nguyên sẽ hết bạ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 ð beader

Trong IITTP/L.L 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áo mệnh đề điển kiện, được dùng để

điển khiến máy khách cache tài nguyên như thề nào [1-1]

Xác nhận

Xác nhận cho phép mná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 đừng được nữa hay không

1.6 Tại sao lại chọn REST

4c va cdc Igi ich như đã trinh bảy ở trên má RHST có thể đưa lại thí có thể dưa ra một số lý do chon REST nhu sau:

Với các ngưyi

Thứ nhất, mỗi đối tượng vật lý hoặc khái miệ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 dién này thi cũng tạo dé dang cho người đùng và giảm tải che máy chủ nêu như tài nguyên chỉ truy cập với một yêu cầu đuy nhất,

19

Thứ hai, với nguyén tac phi trang thai thi 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 cach phủ hợp Cac anh hưởng khác của nguyên tắc này đó là cân bằng tải

phức lạp không cân thiết và máy khách đang sử dụng hệ thống mã rnáy chủ bị mất kết nội thì máy chủ cfng không phải thông ban cho máy khách và xem đó là lễi của hệ thẳng

'Thử ba, nếu dich vụ không theo RESTful thì các dịch vụ rất khỏ để có thể liên kết

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 1FI'LP sử dựng trong mỗi yêu cảu không theo một mẫu chuẩn

Theo kiểu kién tic REST thi may khách có thế đoán được giao diện tương táo đượ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ử đụng UEI chỉ định hoặc điều hướng qua đại diện sứ dựng các liên kết

Với các lợi ich như trên thi REST 1A 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 địch vụ theo nhiều cách có thể

1.7 Dịch vụ web RESTful

Với khải niệm địch vụ RHSTful 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à dich vy RESTful RE!

dưới của web, bởi vậy áp dụng các nguyên tắc RLST có nghĩa là sẽ tích hợp trực tiếp vào

là kiểu kiến trúc tảng,

web hon la tap trung vào các chức năng Dịch vụ E.HSTful sử dụng tài nguyên web như là các khái niém trou tuong chinh [4,6]

Dich vu 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 va phố biên dượ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ê thi có thể được cung cắp trong HTML cho người đừ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

20

« Giao điệ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 la van dé

©) Lin cache có thể lâm tăng khả năng thực hiện

+ HTTP duoc 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

TITTP được kết thừa vào trong địch vụ RISTÊI|, các tính năng quan trọng như mã

hóa, xác thực va cache

Các vẫn đề thuận lợi này được cìmg cấp phỏ biến trong dich vu web 2.0 để phát triển địch

vụ RBSTÔH như Yahoo, Amazm, Fhekr

21

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

2.1 Giới thiệu

Trong vai năm gần đây thi việc xây đựng dich vu RESTful trong java gắn liên với các

servlet API, nếu bạn đã xây đựng ứng dụng web trong java thi hẳn bạn đã rất quen với

servlet Servlet mang dén cho bạn một giao thức HTTP rat gần gủi, tắt nhiên là yêu cau

rất nhiêu mã lập trình trang quá trình phát triển để chuyển đếi cáo thông tỉn từ một yêu

câu HTTP Vào năm 2008 một đặc tä mới được gọi là IAX-RS được định nghĩa và hỗ trợ thực thi cae dich vu RESTful

JAX-RS [1] la mét framework ma tip trang vao tng dung ánh xạ các ký hiệu java với

các đổi tượng java rõ ràng, Nó có cáo ký hiệu để ràng buộc các mẫu UBI cụ thể và các

toán tứ HLTP tới cáo phương thức riêng của lớp java Mó cũng có các kỷ hiệu anh xạ

tham số mà cỏ thể giúp bạn đễ đảng lây các thông tin từ yêu cầu IITTP Nó cũng có phan

thân thông điệp như reader và writer cho phép bạn tách riêng các định dạng đữ liệu từ các

đổi tượng đữ 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áo cơ chế phủ hợp với sự điều chỉnh nội đụng của ITTTP

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

Đổ tim hiểu kỹ hơn về cách thức sử dụng thư viện JAX-R5, chủng †a sẽ tìm hiểu qua vi

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áo phương thức set, get này,

lớp này được định nghĩa như sau:

public class Customer {

private int id,

private String firstName;

private String lastName,

'Tạo một lớp Customeritesource thực thi dich vu JAX-RS

2

import .;

@Path("/customers")

public class CustomerResource {

private Map<Integer, Customer customerDB =

new Concurren{HashMap<Integer, Customer>(),

CustomerResource lả lớp java tường minh, ky higu @javax.ws.rs.Path duge đặt ở đầu lớp CustomerResouroe cho ta biết đang sử đụng địch vụ TAX-R5, lớp java muốn nhận ra đị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, gid tri nay cho biết rằng đây là đường dẫn góc của địch vụ customers, néu

đường dẫn tuyệt đổi của địch vụ là http://sbop.restfully.eom thì đường dẫn của dịch vụ sẽ 1a bttp://shop restfilly.com/customers

Trong lớp java chúng ta có thể định nghĩa các phương thức kháe nhau, thực hiện các chức

ră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ở đữ liệu và sử

đụng các tiện ích trong các gói java

2.2.1 Tạo mới mit customer

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

một eustomer như sau:

@POST

(Consutres(" applicafiow/xml”}

public Response createCustomer(InputStream is) {

Customer customer readCuslomer(isy,

customer.seld(idCounter.incrementAndGet());

cuslomerDB pul(customer geld), customer);

System oul printn(" Created customer * + cũsLorner.gelldO);

retum Response created(URI create("/customers/"+ customer.gctld()}).buildO,

số, tạo mới mệt đối tượng customer rồi ghi vao ca sở đữ liệu, phương thức này sẽ trả về

một mã 201 (ạo mới thành công) nêu phi dữ liệu thành công,

Đổ ràng buộc yêu câu HTTP POST dõi với phương thức createCustomer(), ta sẽ sở dụng

ký hiệu (@javax.wsrs.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à dược gửi dến URL /customers sẽ đo phương thức crcatcCustomer() tiếp nhận và xử lý

Ky hiệu @javax.ws.rs.Consumes trong trường hợp này áp dụng cho phương thức

createCustomer() chi ra kiéu dir ign can phai tao để trả lại cho người dùng theo yêu cầu, riếu một kiêu đữ liệu khác, không phải la XML thủ một mã lỗi sẽ trả lại chơ người dùng

2.2.2 Nhận thông tin custonter

Ta sẽ xem xét việc nhận thông tin như thế nào khi có yêu cau GET /customers/{id}, với

{id} 1 ma customer, ham nhận thông tin customer duge thue thì nhự sau:

return new Streaming Output() {

public void write(OutputStream outputStream)

throws lOLxception, WebApplicationiixception {

nải với giá trị của ky higu @Path ma ching ta 43 ap dung đổi vai lop CustomerResource, chúng ta cũng sử đụng ký hiệu (@javaxwsrsProduces đối với phương thức

getCustomer() dé chi cho JAX-RS biết kiếu đữ liệu trả về cho máy khách là

application/xmI

GetCustomerQ nhận một đối số éi số nảy xác dịnh customer mà máy khách yêu cau, chúng ta sử dụng id nay để truy vấn trong cơ sở dữ liệu Ký hiệu (javax.ws.rs.PathParam sẽ thông báo cho JAX-R8 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ố fid} được lẫy từ /customers/{id} Vi du néu URL yéu cdu GUT

đến Ja hitp://shop sestfully.com/customers/333, thi gid trị xâu 333s8 duoc cdf ra tty URL,

chuyển nó thành kiêu số r:

pan né vao gid trị iđ 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 /onstomors/fid} ti 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é cai đặt phương thức cập nhật khách hàng như

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

Customer update = readCustomertis),

Customer cuzrent = customerDB.get(id),

Trong phương thức updateCuslomerQ) chúng ta sử dung ky hiGu @javax.ws.rs.PUT dé

ràng buộc yêu cầu HTTP PUỤT với phương thức này Cũng giốn;

getCustomerQ 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 nhu getCustomor(} ching ta st dung ky higu @PathParam dé cdt id ty UURI yêu cầu đến và một tham số thử hai cho phép

dọc XML

như phương thức

25

2.3 Cac toan tt LIT TP va anh xa URI

Trong phan trên chúng la vừa mới sử dựng các ký liệu @GBT, @PUT, (@POST, và

@DELETE dễ ràng buộc với các phương thức java với các toán tử của HTTP Ching ta cũng đã sử dụng ký hiệu (ðPeth dễ ràng buộc với các phân doan 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 chỉ tiết hơn các ký hiệu dỏ

wong phan nay

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ử TTTTP:

Chứng ta đã sử đụng đã sử đựng các ký hiệu này đề tham chiếu với các yêu cẩu IITTP

GET vai cae phương thức java, chẳng hạn như:

ở đầ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 IITTP GIT tới URI /eustomers Một trong năm ký hiệu khác sẽ được sử đụng để ràng buộc với cáo toán

tử HTTP khác Chủ ý mệt điều rằng ta chỉ có thế áp đụng mỗi ký hiệu HTTP cho mỗi

phương thức Java Một mã lỗi

ẽ được trã lại nêu ting dung whiéu bon một ký hiệu

2.3.2 Ky higu @Path va thy chon mé ring

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 dịnh các yêu cầu ràng buộc khac trong URL,

@Path cũng có thể được dùng ở đầu phương thức java đề phản chia ludng yêu cầu tải nguyén con của ứng, dụng,

Ký liệu @DPath được định nghĩa trong JAX-RS để xác định cả

c tham sô phủ hợp trong

URI đến của yêu cau HTTP Ky hiệu này có thế được đất ngay đầu lớp java hoặc một nơi bal ky mio 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ó íL nhất mội mô tâ @PathC°2Đ, 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á L/RI liên quan đến nội dung gốc của

tp dụng, Để nhận một yêu cầu, lớp java phải có it nhất một kỷ hiệu mà H†'FP cần nhận

ra được áp dụng là @GITT mà không yêu câu ký hiệu @Path, vi du:

Mét yéu cau HTTP GET toi /orders va phim bé 16i phuong thee gelANOrders(), @Path

cũng cô thể được áp dụng trong lop java, gia tri sẽ kết hợp voi gia tri @Path ở ngoài lớp

để xác định tài nguyên, ví dự:

27

Bởi vậy trong trường hợp ubir bén thi lai nguyén được xác định thông qua ham

getUnpaidOrders() với địa chỉ /orders4unpaid,

ấy thông tin Lừ yên cau HTTP va ánh xạ

lo các phương thức java Điều mà chúng ta quan tâm đó là cdc tham sé trong URT đến, cũng có thể là các giả trị xâu truy vận trong URT Máy khách cũng có thể gửi cáo mã

le yêu cầu TAX-RS cho phép bạn năm bắt các thông tim này khi bạn cân nó thông qua các ký hiểu ảnh xạ và

APIs

HTTP trong giá lrị header hoặc giá tri cookie mà địch vụ cần xử lý

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

© @javax.ws.rsPalhParam: ky higu nay cho phép bạn trích lọc các giá tri lừ các

tham số tam dura vao tit URT

© @javax.ws.rs.QueryParam: ky higu nay cha phép ban trich low cae gia ti lis ede tham số truy van vao Lit URT

© @javax.ws.rs.FormParam: ky bigu nay cho phép bạn trích lọc các giá Irị từ dữ liệu trên [am gũi vào

® (Đjavax.ws.rs.MalrixParan: ký hiệu này cho phép bạn trích lọc các giá trị lừ các

tham sé dang ma tran vao tr URL

* @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

28

© @javax.ws.rs.CookieParam: ky higu nay cho phép ban trich loc cée gid trị từ

cookle của HTTTP đượ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 TAX-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 Mến phương thức java có tham số thi chúng sẽ được khai bán ngay phía sau các

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

xa 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 construoor

‘Trong vi dy trên hướng yêu cầu tài nguyên của HIIP theø UIRI /customers/ {i4}, phương

thức getCustomerQ sẽ trích lọc xnã 1D từ LIRI bằng cách sứ dụng (@)PathiParam, giá trị của

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

số mà ta định nghĩa trong (ØPath của phuơng thức getCustomer(

{iđ} là một xâu mô tả trong yêu cầu URT, TAX-RS sẽ tự động chuyển sang gia trị nguyên trước khi phương thức getCustomer() sử dụng Néu các tham sé string dong dan URI

không thể chuyên đổi thành kiểu nguyên được thì lúc đỏ một mã lỗi sẽ được tả về cho

máy khách từ máy chủ

29

Bạn cũng có thế truyền nhiễu tham sẻ vào đường dẫn LTRT vào trong lớp java của bạn, vi

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

@Path("/customers")

public class CustomerResource {

@Path(" {first} - {last} ")

@GET

@Produces(“application/xm!")

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

@PathParam{"tast") String lastName) {

Ở đây chúng ta có các tham số rong URI là {first} va {last}, néu máy khách yêu cầu một

HTTP 1a GET /customers/bill-burke, thi bill sé duoc anh xa vao tham sé firstname con

burke sé duoc anh xa vao tham sé lastname

Đôi khi các tên tham số trong URI sẽ dược lặp di lặp lại tong các biểu thức của @ÿPath, các tham số này được truyền dây đủ vào từ URI, tham số trước có thẻ bị thay thể bởi tham số sau, xác định mục tai nguyén con 1rong trường hợp dé ky higu @PathParam

luổn luôn tham chiều đến tham só cuỗi củng, vỉ dụ:

Từ ví đa trên ta thấy nếu yêu câu la GET /eustemers/123/address/456 thì tham số

addressid trong phương thúc getA đđress() sẽ có giá trị là 456

2.4.3 @QueryParam

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

sé java cia ban Chang han chứng ta mudn truy vấn customer từ cơ sở đữ liệu và nhận

một tập con cáo cusLomer từ cơ sở đứ liệu, lúc đó URI truy vẫn có dạng:

GUI /customers?start-O&size=10

Tham sé start là chỉ số bắt đâu mà ta muốn truy vấn từ cơ sở đữ liệu và size là số hượng

customer mà ta muôn nhận Khi đó dịch vụ JAX-RS sẽ được thực thi như sau

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

@QueryParamf" size") int size) {

‡

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

“start” và “size” vào các tham số java là s†art và size, các tham số nảy JAX-RS sẽ tự động

chuyển đổi từ đang x4u thanh 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ố

chọn những tham số mình cân, Interface javax.ws.1s.oore Urlnfo 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 dang tray van đến:

rồi

public miterface UniInfo

public MultivaluedMap<String, String> gotQueryParameters(),

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

31

Bạn có thế ánh xạ thể hiện Uninfo sit dung ky higu @javax.ws.rs.core.Context Sau đây 1à ví vụ về việc sử đụng lớp này dé anh xa va ky higu @Context 46 nhận một số tham số

can thiét trong URI dén:

@Path("/customers”)

@GET

@Produces("application’xm!")

public String getCustomers(@Context Urilnfo info) {

String start = info.getQueryParameters().getl irst("star†"),

Swing size = info.getQueryParameters().get!"ixst("size”);

2.4.4 @FormParam

Ky higu @javax.ws.rs.FormParam được sử dụng để Iruy cập dạng form application’x-

wwau-fomairleneoded 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 HTMIT, Ví đụ chứng 1a Huệt lập rnột [orm nhập liệu một khách hàng mới lrên wehsite của chưng ta như sau:

<TORM action=“hitp://example com/eustomers” method="post">

First name: <INPUT type

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

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

@Path("/customers")

public class CustomerResource {

@POST

public void — createCustomer(@FormParam("firstname"} — String _ first,

@FormParamd" lastname") String last) {

}

Như vậy ở ví đụ 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 Ja first va last Form đử liệu khi đến dịch vy JAX-RS là một dạng

URL-eneoded Khi sử dụng (FormParam, TAX-R§ sẽ tự động giải mã các giá trị từ form

và ảnh xa vào các tham số lương ứng,

33

Chương 3: Bao mat véi dich vu RESTful

Chương này sé ban é bao mat voi dich vu RLSTfal, cdc phuong 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

Dich vu web theo kién tnic REST dang trở nên phê biển qua nhiều ứng dụng gắn liền với các dịch vụ dé dang cho sự phát triển Dịch vụ dựa vào các toán tứ chuẩn của ITETP như GET, POST, PUT va DELETE, két qua tra vé của dịch vụ phụ thuộc vào ứng dụng, có

thể là XML, JSÓN, TEXT hoặc dịnh dạng khác,

Thương pháp phố hiên hiện tại cho việc hảo mật bao gêm xác thục người dùng và bảo mai lang 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 mang bang 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ự liều biết về liên kết và xác nhậu của người đừng, címg dựa vào nhược điểm này mả van dé lừa đảo đã xây ra qua mạng Cookics của wcb được sử dụng dễ truyền thông tin và thực hiện các thông tin bão mật trong yêu câu LITTP 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ái, hoặc kiểm soát yếu các thông tín 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 đù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 ƯRT, hoặc có thể truyền các thông lin đã dượ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

đừ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 thí ứng dụng web, nhiều ứng dụng được thực thí 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 lan ting Li trong cia may chủ và điều này cũng không giúp được các nha cung cấp dich vụ dễ dàng mở rộng dược các dịch vụ của họ khi số lượng may tram kết nổi cao Dây là một trong các vẫn để rất quan trọng cho các ứng đụng web ngày nay

Mi trong các mô hình có thể đáp ứng dược vẫn dễ này dó chính là RBST 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 đụng web có khả năng mở rộng, chang

han nó cho phép máy chủ có thể là phi ưạng thải hoặc ứng đụng lợi ích của việc lưu giữ

nhiều URI tính Trong kiểu kiến trủe REST URI có thé được tham chiếu dén sau phiên làm việc, đầy cũng là điều má các rô hình ứng dung khác khó có thể đạt được

34

Tuy nhiên vẫn có khoảng cách giữa kiến trúc web vả oác tính năng bão mật hiện tai, co

chế bảo mật của web ngày may không phù hợp với kiên trac 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 dị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 duợc Điều này làm giảm khả rằng mở rộng của kiến trac 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 1TU'LP 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 va DELETE( ngoai ra can có cáo phương thức khác như HBAH, CONNECT hoặc TRACE tuy nhiên chúng 1a không bản luận các phương Hhúc tãy ở

day), REST diễu khiển tất cả các URI va cae phương thức HTTP áp dụng với chúng Ni một cách tổng quát hơn thi GET duoc xem như là hành động để đạc đữ liệu, PUT là hành

động cập nhật đữ liệu, POST là hành động tạo mới đữ liệu và DELETE là hành động xóa

dữ liệu, GEI (cũng như HHAD) được xem là hảnh động an toàn vì nó không làm thay

đối đà Hệu nhưng các hành động cẻn lại nói một cách nào đó thì chúng lam thay di dir

liệu

Lu trữ nội đụng của web cẩn gắn liên với các UEI, các URI nay được gán với các mục

dữ

liệu cần phải dược chuyên cến người dùng thông qua trình duyệt web vá dược lấy từ máy

chủ web qua thao tác ITTP GIT Gitta may tram 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,

Tiêu là một phẩn quan trọng của RESTRU và ứng dụng phương thúc HTTP GET, Dữ

Gõ nhiều mô bình bộ đệm web được thực thì trong từnh duyệt web và chỉnh trong các

may trạm của chủng, như bộ dệ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(nternet Cache Prolocol), HTCP (Hyperlext Caching Protocol) Hon nita 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 địch vụ Giao thức ITTTP có cơ chẻ đẻ có thể điều khiển được bộ đệm cho phép

bộ đệm cung cap 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 dược sử dụng trong bộ đệm dễ 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 RBSTful đó 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 nhưng để cho máy chủ xử lý các hoạt động và cung cập kết quả trả lại Nói một cách khác

35

nếu HTTP GET được thiết kế đề sử đụng như la một phương thức triệu gọi từ xa cho việc

ghi đữ liệu thì bộ nhớ đệm sẽ xem rữnư là đã có một kết quả trong đó cho URI va tr lai

kết quả cũ Điều này hoản toàn dứng cho ứng dụng và dịch vụ logic Kiểu kiến trúc RHST thực thi ứng đụng web đua 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 đự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

Ung dung web trong kiếu kiến trúc RBST tạo ra các URI theo cach ma cdc video hoặc

hình ãnh có thể dễ đăng được lãm 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 dược đỡ 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 dung

ác phiêu lồm việc bão mật với TL§ và chuyển tắt cả các dữ liệu vào một kênh bảo mật

riêng thi vấn dé 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 đữ liệu, sinh ra dư thừa mã hóa Nhưng bủ lại thi

đữ liệu được an toàn và phiên làm việc của người đùng được bão mi Một giải pháp có

thé dé cái thiện vẫn để nảy là vô hiệu hóa bộ nhớ đệm chung vả áp dung các ứng đự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ên cầu nên ứng dung xác định bộ nhớ đệm và không sử dụng các lợi ích của bộ nhở dệma proxy Nó cũng yêu cau may chi mai hóa dữ liệu khi truyền qua các đường truyền riêng, điều này cũng sinh ra đư thừa mã hỏa,

yêu cầu báo một đữ liệu trong máy chú sau khi k

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 wcb thương mại yêu cu người dùng phải trả phí chơ nội dung

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

họ muốn kiến trúc pủ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ở dệm vẻ mã hỏa nội

dưng

Vấn dé nay sẽ dược giải quyết miột cách dơn giản, chúng tá sẽ tạo một khỏa bao mat n6i

dung Tay chon gin thai gian sống, của khóa đó với thời gian của bô nhớ đệm của URL va cung cấp khỏa này cho các khánh hàng được phép truy cập nội dụng Tất cả đữ liệu được

mã hóa với khỏa bảo mật nội dung, sau dó dược lưu giữ phia ngoài dịch vụ Chúng ta yêu

cầu xác thực người ding và quyết định ửy quyển truy cập nội dưng(chẳng bạn như thông qua TLS hoặc chứng thực HTTF và cơ chế cấp quyền) Dữ liệu thực tế san đó được truy

36