congngheweb cd23 restful&json phamchienthang nguyenmanhhoang

ĐẠI HỌC BÁCH KHOA HÀ NỘI

VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

----------

BÀI TẬP LỚN

Môn: Công nghệ web và dịch vụ trực tuyến

Đề tài: Tìm hiểu RestFul API và JSON

GV hướng dẫn: TS. Tạ Tuấn Anh

Sinh viên thực hiện:

1. Phạm Chiến Thắng 20082485

2. Nguyễn Mạnh Hoằng 20081088

Hà Nội 11/2012

CĐ23: Restful API & JSON

MỤC LỤC

Contents

Mở đầu......................................................................................................................4

I. Dịch vụ mạng RestFul......................................................................................6

1. Khái niệm.....................................................................................................6

2. Đặc tính.........................................................................................................6

3. Mục tiêu chính...........................................................................................13

4. Ràng buộc...................................................................................................14

a. Clien-Server............................................................................................14

b. Stateless...................................................................................................14

c. Cacheable................................................................................................14

d. Layered system.......................................................................................15

e. Code on demand.....................................................................................15

f. Uniform interface...................................................................................15

5. Cài đặt RESTful Web service với Java (JAX-RS) sử dụng Jersey.......15

a. JAX-RS và jersey....................................................................................15

b. JAX-RS annotations...............................................................................16

c. Các bước để phát triển web servieces sử dụng RESTful với Java.....17

d. Demo đơn giản về RESTful webservice...............................................17

6. Đánh giá......................................................................................................22

II. JavaScript Object Notation – JSON.............................................................23

1. Khái niệm...................................................................................................23

2. Đặc điểm.....................................................................................................23

a. Data types, syntax and example............................................................23

b. Các giá trị của JSON..............................................................................24

c. JSON làm việc như thế nào...................................................................25

Công nghệ web và dịch vụ trực tuyến 2


3. Triển khai ứng dụng JSON.......................................................................28

a. Phương pháp triển khai một ứng dụng JSON.....................................28

b. Demo ứng dụng.......................................................................................29

4. JSON và XML. Đánh giá ưu nhược điểm...............................................38

a. JSON và UML............................................................................................38

Tham khảo..............................................................................................................41



Mở đầu

Ngày nay, công nghệ thông tin đang là nền công nghệ mũi nhọn trong chiến

lược phát triển kinh tế, xây dựng đất nước của hầu hết các quốc gia. Các sản phẩm

công nghệ thông tin đã và đang được ứng dụng rộng rãi trong mọi lãnh vực của

đời sống kinh tế, xã hội và hầu hết đều đem đến những giá trị thiết thực. Với sự

phát triển của internet và với xu thế hội nhập chung của toàn thế giới, các tổ chức,

các cơ sở doanh nghiệp cần bắt tay, phối hợp hoạt động và chia sẻ tài nguyên với

nhau để nâng cao hiệu quả hoạt động. Lúc này các sản phẩm sẽ có độ phức tạp lớn

hơn, từ đó kéo theo các vấn đề liên quan như chi phí sản xuất, chi phí quản lý và

bảo trì. Bên cạnh đó, ngành công nghệ phần mềm còn phải đối mặt với các khó

khăn trong xu thế mới như vấn đề an ninh bảo mật, vấn đề tái sử dụng và mở rộng

các hệ thống sẵn có, vấn đề về sự không tương thích giữa các hệ thống khác nhau

của nhiều tổ chức …Để giải quyết các vấn đề trên, nhiều giải pháp đã được nghiên

cứu và ứng dụng. Nhưng hầu hết các giải pháp này không giải quyết các khó khăn

một cách triệt để và kết quả đạt được cũng không như mong đợi. Hiện nay, một giải

pháp mới đang được cộng đồng công nghệ thông tin rất quan tâm, đó là “Kiến trúc

hướng dịch vụ” (Service-oriented Architecture - SOA). Giải pháp này bước đầu

đã được ứng dụng trong một số dự án và đều đem lại những kết quả khả quan.

RESTful và JSON là 2 trong số rất nhiều những vấn đề được nghiên cứu,

phát triển và thực hiện trong kiến trúc hướng dịch vụ SOA.

RESTful ( REpresentational State Transfer ) xác định một nhóm các

nguyên lý kiến trúc, bằng cách đó bạn có thể thiết kế các dịch vụ mạng, chú trọng

vào các tài nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng như



thế nào và được chuyển tải qua HTTP thông qua một lượng lớn người dùng và

được viết bởi những ngôn ngữ khác nhau. Nếu tính theo số dịch vụ mạng sử dụng,

REST đã nổi lên trong một vài năm qua như là một mô hình thiết kế dịch vụ chiếm

ưu thế. Thực tế là REST đã có những ảnh hưởng lớn đối với mạng và gần như

chiếm vị trí của thiết kế giao diện dựa trên SOAP hay WSDL vì nó là cách thức

đơn giản hơn rất nhiều để sử dụng.

JSON (JavaScript Object Notation) là một định dạng trao đổi dữ liệu hạng

nhẹ mà con người có thể đọc được và máy tính dễ dàng phân tích cú pháp được. Nó

dựa trên một tập hợp con của ngôn ngữ lập trình JavaScript, tiêu chuẩn ECMA-262

(3rd Edition - Tháng 12 năm 1999 ). JSON được phổ biến bởi Douglas Crockford

bắt đầu từ khoảng năm 2001. JSON ra đời nhằm cạnh tranh với XML. Vời nhiều

ưu thế JSON hứa hẹn sẽ đuổi kịp sự phổ biến của XML trong tương lai

Trong bài nghiên cứu này, chúng ta sẽ tìm hiểu kỹ hơn về RESTful và

JSON. Hi vọng qua bài nghiên cứu này đem lại cho bạn đọc cái nhìn rõ rang hơn

về những công nghệ mới này. Bài nghiên cứu còn có những thiếu sót, chúng tôi rất

mong nhận được sự góp ý của bạn đọc để chúng tôi có thể hoàn chỉnh hơn bài

nghiên cứu này.



I. Dịch vụ mạng RestFul.

1. Khái niệm

REpresentational State Transfer (REST) xác định một nhóm các nguyên lý

kiến trúc, bằng cách đó bạn có thể thiết kế các dịch vụ mạng, chú trọng vào các tài

nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng như thế nào và

được chuyển tải qua HTTP thông qua một lượng lớn người dùng và được viết bởi

những ngôn ngữ khác nhau. REST là một cách suy nghĩ, không phải là 1 giao thức

hay tiêu chuẩn (REST is a way of thinking, not a protocol or standard)

REST thực hiện cơ chế nói chuyện giữa server và client là điểm điểm – point

to point. Dữ liệu được truyền trực tiếp trên HTTP và được truy cập thông qua

HTTP theo đúng định dạng MIME mà không cần thông qua dạng SOAP – giảm bớt

sự phức tạp – vì đơn giản chúng ta sẽ coi dữ liệu và chức năng như là tham số

truyền hay dữ liệu đính kèm trong HTTP. REST Cho phép thao tác dữ liệu dưới 4/7

phương thức được định nghĩa trong HTTP đó là GET, POST, PUT, DELETE để

qui định rõ cách thao tác dữ liệu trên server, cái nào được truy cập, các nào được

sửa đổi, cái nào được hiển thị và dấu ẩn …

2. Đặc tính

Phong cách kiến trúc REST được phát triển song song với HTTP/1.1, dựa trên

thiết kế đã có của HTTP/1.0. Sự bổ sung lớn nhất của một hệ thống phù hợp với

kiến trúc REST là World Wide Web. Kiến trúc REST bao gồm clients và servers.

Clients gửi yêu cầu tới servers; servers xử lý yêu cầu và trả về đáp ứng thích hợp.

Yêu cầu và đáp ứng được xây dựng xung quanh việc chuyển giao đại diện của

nguồn tài nguyên. Một nguồn tài nguyên có thể là bất cứ khái niệm nào được đánh

địa chỉ. Một đại diện của nguồn tài nguyên thông thường là một tài liệu ghi lại

trạng thái hiện tại hoặc dự định của một tài nguyên. Clients bắt đầu gửi yêu cầu khi



nó sẵn sàng chuyển đổi sang trạng thái mới. Trong khi một hay nhiều yêu cầu còn

tồn tại, chưa được giải quyết thì client đó được xem xét trong quá trình chuyển tiếp.

Đại diện của mỗi trạng thái ứng dụng chứa liên kết mà được sử dụng trong lần

client lựa chọn tiếp theo để bắt đầu một trạng thái chuyển đổi mới. REST tạo điều

kiện cho việc trao đổi giữa các máy chủ web bằng cách cho phép khớp nối lỏng lẻo

giữa các dịch vụ khác nhau.

Một đặc tính quan trọng của dịch vụ mạng RESTful là sử dụng một cách rõ

ràng phương thức HTTP theo cách một giao thức được xác định bởi RFC 2616. Ví

dụ HTTP GET được xác định như là một phương thức sinh ra số liệu mà được sử

dụng có chủ đích bởi các ứng dụng người dùng để thu thập được tài nguyên, thu dữ

liệu từ một máy chủ mạng, hoặc thực thi một truy vấn mà máy chủ mạng sẽ tìm

kiếm và phản hồi cùng với một gói tài nguyên tương thích.

REST yêu cầu các chuyên viên phát triển sử dụng phương thức HTTP một

cách rõ ràng theo cách tương thích với giao thức chuẩn. Nguyên lý thiết kế REST

cơ bản này thiết lập một ánh xạ 1-1 giữa các hoạt động tạo lập, đọc, cập nhật và

xoá các phương thức (CRUD) và phương pháp HTTP. Theo phương thức ánh xạ

này:

Để tạo một tài nguyên trên máy chủ, sử dụng POST.

Để truy xuất một tài nguyên, sử dụng GET.

Để thay đổi trạng thái một tài nguyên hoặc để cập nhật nó, sử dụng PUT.

Để huỷ bỏ hoặc xoá một tài nguyên, sử dụng DELETE.

Một thiết kế không may bị hỏng dễ nhận ra trong nhiều mạng APIs là phương

thức sử dụng HTTP cho các mục đích không dự tính trước. Ví dụ lệnh URI trong

một lệnh HTTP GET thường xác định một tài nguyên cụ thể. Hoặc một chuỗi truy

vấn trong một lệnh URI bao gồm một nhóm các tham số xác định tiêu chí tìm kiếm



được máy chủ sử dụng để tìm các tài nguyên phù hợp. Ít nhất điều này cho thấy

HTTP/1.1 miêu tả GET như thế nào. Nhưng có nhiều trường hợp Web APIs không

được tốt lắm, do sử dụng HTTP GET để khởi động một vài tác vụ trên máy chủ —

ví dụ, thêm các bản ghi vào một cơ sở dữ liệu. Trong các trường hợp này, GET yêu

cầu URI không được sử dụng đúng đắn hoặc ít ra không sử dụng REST một cách

đầy đủ. Nếu Web API sử dụng GET để ra lệnh từ xa một quy trình, nó sẽ có dạng

như sau:

GET /adduser?name=Robert HTTP/1.1

Đây không phải là mẫu thiết kế hấp dẫn vì phương pháp mạng nói trên hỗ trợ

phương thức thay đổi trạng thái trên HTTP GET. Nói cách khác, phương pháp

HTTP GET yêu cầu nói trên có những tác động phụ. Nếu được xử lý thành công,

kết quả của yêu cầu này là để tạo thêm vào người sử dụng mới vào mẫu này —

trong ví dụ này, Robert — đối với việc lưu giữ số liệu cơ bản. Vấn đề ở đây chỉ về

mặt ngữ nghĩa. Những mạng máy chủ được thiết kế để tương thích với các yêu cầu

của HTTP GET bằng cách truy lại mã nguồn phù hợp với đường dẫn (hoặc là tiêu

chuẩn yêu cầu) theo như câu lệnh URI và gửi lại những mã nguồn này hoặc là

thông tin đại diện mà không thêm mẫu dữ liệu vào cơ sở dữ liệu. Từ góc độ mục

đích sử dụng giao thức đó và từ phương pháp HTTP/1.1-compliant của mạng chủ

thì sử dụng GET theo cách này sẽ không thống nhất

Trên mặt ngữ nghĩa, vấn đề khác cùng với GET là để khởi động một sự xoá

bỏ, sửa đổi, hoặc ghi thêm vào cơ sở dữ liệu, hoặc để thay đổi trạng thái máy chủ

theo một cách nào đó. Nó kéo các công cụ lưu trữ web (các đường dẫn) và các công

cụ tìm kiếm, để làm thay đổi máy chủ một cách không chủ định theo cách đơn giản

bởi một đường dẫn. Một cách đơn giản để vượt qua vấn đề hay xảy ra này là dịch

chuyển tên và giá trị các tham số dựa trên đòi hỏi URL đối với các thẻ XML. Các



thẻ kết quả, một đại diện XML của một chủ thể được tạo ra, có thể được gửi vào

một nhóm HTTP POST, những nơi mà yêu cầu URL là chủ thể sinh ra có chủ đích

(xem ví dụ 1 và 2).

Ví dụ 1. Trước

GET /adduser?name=Robert HTTP/1.1

Ví dụ 2. Sau

POST /users HTTP/1.1

Host: myserver

Content-Type: application/xml

<?xml version="1.0"?>

<user>

<name>Robert</name>

</user>

Phương pháp trên là ví dụ của lệnh RESTful: cách sử dụng đúng HTTP POST

và bao gồm cả tải trọng trong phần thân câu lệnh. Đối với phía đầu tiếp nhận, câu

lệnh có thể được xử lý bằng cách thêm tài nguyên vào hệ thống đó như một phần

phụ tài nguyên được định dạng trong lệnh URI; trong trường hợp này tài nguyên

mới phải được thêm vào như là một nhánh con của /users. Quan hệ bao hàm giữa

thực thể mới và nhánh mẹ, như đã xác định trong yêu cầu POST, tương tự như cách

tệp đã thuộc thư mục mẹ. Máy khách thiết lập quan hệ giữa thực thể và nhánh mẹ,

và xác định URI của thực thể mới trong yêu cầu POST.



Ứng dụng máy khách sau đó có thể nhận kết nối của nguồn sử dụng URI mới,

lưu ý rằng ít nhất về mặt logic, nguồn được đặt dưới /users, như trong ví dụ 3.

Ví dụ 3. Lệnh HTTP GET

GET /users/Robert HTTP/1.1

Host: myserver

Accept: application/xml

Sử dụng GET theo cách này rất rõ ràng vì GET chỉ dành cho truy cập dữ liệu.

GET là một phương thức mà không có hiệu ứng phụ, như là một đặc tính riêng

không thay đổi giá trị.

Một cách chỉnh lại của phương thức mạng cũng cần được ứng dụng trong các

trường hợp khi một thao tác cập nhật được hỗ trợ qua HTTP GET, như thể hiện

trong ví dụ 4.

Ví dụ 4. Cập nhật đối với HTTP GET

GET /updateuser?name=Robert&newname=Bob HTTP/1.1

Điều này thay đổi thuộc tính (hoặc đặc tính) name của tài nguyên. Trong khi

chuỗi truy vấn có thể được dùng cho những phương thức như thế này, và ví dụ 4 là

một ví dụ đơn giản, mẫu phương pháp dấu hiệu như là chuỗi truy vấn (query-string-

as-method-signature) có xu hướng chia rẽ khi được sử dụng đối với các phương

thức phức tạp hơn. Do mục tiêu của chúng ta là sử dụng phương pháp HTTP một

cách rõ ràng, cách tiếp cận RESTful là gửi một yêu cầu HTTP PUT để cập nhật tài

nguyên, thay vì HTTP GET, cho những lý do tương tự chỉ ra ở trên (xem ví dụ 5).



Ví dụ 5. Lệnh HTTP PUT

PUT /users/Robert HTTP/1.1

Host: myserver

Content-Type: application/xml

<?xml version="1.0"?>

<user>

<name>Bob</name>

</user>

Sử dụng PUT để thay thế tài nguyên gốc, cung cấp một giao diện sạch hơn,

phù hợp với các nguyên lý của REST và các khái niệm của phương pháp HTTP.

Lệnh PUT trong ví dụ 5 rõ ràng ở chỗ nó chỉ ra tài nguyên được cập nhật bằng cách

xác định nó trong câu lệnh URI, và nó chuyển một đại diện mới của các thuộc tính

tài nguyên chuyển đổi như là nhóm không chặt chẽ các tên tham số và giá trị trên

lệnh URI. Ví dụ 5 cũng có hiệu ứng từ việc đổi tên tài nguyên từ Robert sang Bob,

và trong việc các thay đổi của URI sang /users/Bob. Trong một dịch vụ mạng

REST, lệnh tiếp theo của tài nguyên sử dụng URI cũ sẽ sinh ra lỗi căn bản 404 Not

Found.

Như là một nguyên tắc thiết kế chung, nó giúp theo sát các hướng dẫn sử dụng

REST để sử dụng phương pháp HTTP một cách rõ ràng bằng cách sử dụng các

danh từ trong URIs thay vì động từ. Trong một dịch vụ mạng RESTful, các động từ

— POST, GET, PUT, và DELETE — đã được xác định bởi giao thức. Và tốt nhất,

để giữ giao diện được khái quát hoá và cho phép các khách dùng thông tỏ về

phương thức họ đề xuất, dịch vụ mạng không nên đưa ra nhiều động từ hoặc các

quy trình từ xa, như /adduser hoặc /updateuser. Nguyên tắc thiết kế chung này cũng

áp dụng đối với phần thân câu lệnh HTTP, cái mà được sử dụng có chủ ý để

chuyển trạng thái tài nguyên, không mang tên của một phương thức từ xa hoặc quy

trình từ xa được đề xuất.



Trong một dịch vụ mạng RESTful, máy chủ chịu trách nhiệm đưa ra các phản

hồi và cung cấp một giao diện cho phép máy khách duy trì trạng thái ứng dụng của

chính nó. Ví dụ, trong yêu cầu tập hợp trang kết quả, máy khách sẽ gồm số trang

thực tế khi truy xuất thay vì đơn giản chỉ là yêu cầu tiếp theo (xem hình).

Một dịch Web phi trạng thái sinh ra một phản hồi liên kết với số trang tiếp

theo trong một tổng thể và để máy khách làm những gì mà nó cần để giữ giá trị này

ở mức nhất định. Khía cạnh này của thiết kế dịch vụ Web RESTful có thể được

tách thành hai phần trách nhiệm như là mức phân chia cao nhất mà chỉ rõ một dịch

vụ phi trạng thái có thể được duy trì như thế nào.

Máy chủ

Phát ra các phản hồi bao gồm các đường kết nối tới các tài nguyên khác cho

phép các ứng dụng điều hướng giữa các tài nguyên liên quan. Loại phản hồi này

nhúng các liên kết. Tương tự, nếu các yêu cầu đối với máy chủ hoặc các kho tài

nguyên, thì các phản hồi dịch vụ RESTful điển hình có thể bao gồm các đường dẫn

đến các máy con hoặc các tài nguyên phụ sao cho những phản hồi này được duy trì

kết nối.

Phát ra các phản hồi mà xác định chúng có thể lưu trữ hoặc không phải để

nâng cao được hiệu quả bằng cách giảm số lượng yêu cầu đối với các tài nguyên

trùng nhau và bằng cách loại trừ một vài yêu cầu toàn bộ. Máy chủ làm được như



vậy bằng cách gộp một phản hồi phần đầu HTTP Last - Modified (lần sửa gần

nhất) (giá trị ngày) và Cache-Control (bộ điều khiển lưu trữ).

Ứng dụng máy khách

Sử dụng phần đầu phản hồi Cache-Control (bộ điều khiển lưu trữ tạm) để xác

định lưu trữ tài nguyên (lập một vùng sao chép nội bộ) hay không. Máy khách cũng

đọc phần đầu phản hồi Last-Modified (lần sửa gần nhất) và gửi lại giá trị ngày vào

phần đầu If-Modified-Since (nếu-sửa) để truy vấn máy chủ xem tài nguyên có thay

đổi không. Việc này được gọi là truy vấn có điều kiện, và hai phần đầu đi với nhau

trong phản hồi của máy chủ là mã 304 chuẩn (không sửa đổi) và bỏ qua tài nguyên

thực được yêu cầu nếu nó không thay đổi. Một mã phản hồi HTTP có nghĩa rằng

máy khách có thể sử dụng an toàn một vùng sao lưu nội bộ, được lưu trữ của đại

diện tài nguyên một cách cập nhật nhất, hiệu quả bằng cách vượt qua yêu cầu GET

tiếp theo cho đến khi tài nguyên thay đổi.

Gửi các yêu cầu hoàn chỉnh mà có thể được đáp ứng độc lập bởi các yêu cầu

khác. Điều này đòi hỏi máy khách sử dụng toàn bộ các phần đầu HTTP như chỉ

định bởi giao diện dịch vụ mạng và để gửi các đại diện tài nguyên hoàn chỉnh trong

phần giữa của yêu cầu. Máy khách gửi yêu cầu lập một vài giả thuyết về các yêu

cầu trước đó, sự tồn tại của một vùng của máy chủ, khả năng của máy chủ để thêm

các ngữ cảnh vào yêu cầu, hoặc về các trạng thái ứng dụng mà được giữ giữa các

yêu cầu.

Sự hợp tác này giữa ứng dụng máy khách và máy chủ là cần thiết để có một

phi trạng thái trong một dịch vụ mạng RESful. Nó nâng cao hiệu quả bằng cách tiết

kiệm băng thông và tối thiểu hoá trạng thái ứng dụng về phía máy chủ.

3. Mục tiêu chính



Khả năng mở rộng của các thành phần tương tác thành phần.

Tổng quát hóa giao diện

Triển khai độc lập các thành phần

Các thành phần trung gian để giảm độ trễ, thực thi an ninh và đóng gói các

hệ thống kế thừa.

4. Ràng buộc

a. Clien-Server

Một giao diện thống nhất phân biệt các client từ các server.Việc phân tách

này có ý nghĩa, ví dụ, các client không kết liên quan tới lưu trữ dữ liệu trong mỗi

server, do đó tính di động của client được cải thiện. Các server không liên quan tới

giao diện hay trạng thái người dùng, do đó server có thể đơn giản hóa và tăng khả

năng mở rộng. Server và client cũng có thể được thay thế, phát triển độc lập, do đó

giao diện giữa chúng không bị thay đổi.

b. Stateless

Giao tiếp client-server vẫn có những rang buộc do các đặc tính của client

không được lưu trữ trên server giữa 2 yêu cầu.Mỗi yêu cầu từ bất kỳ client nào có

chứa tất cả các thông tin cần thiết để phục vụ yêu cầu và bất kỳ trạng thái phiên nào

đều được giữ ở client.

c. Cacheable

Như trên www, client có thể lưu trữ tạm thời các đáp ứng. Các đáp ứng phải

tự định nghĩa khả năng cacheable hay không, ngăn chặn việc client sử dụng lại các

trạng thái hay dữ liệu không phù hợp với đáp ứng cho yêu cầu tiếp theo. Quản lý

tốt một phần hay hoàn toàn bộ đệm loại bỏ một số tương tác giữa client-server sẽ

cải thiện được hiệu suất và khả năng mở rộng



d. Layered system

Một client không thể nói theo cách bình thường cho dù nó được kết nối trực

tiếp hay trung gian tới server. Những server trung gian có thể cải thiện khả năng

mở rộng của hệ thống bằng cách kích hoạt cân bằng tải (load-balancing) và cung

cấp chia sẻ bộ đệm. Chúng cũng có thể được cài đặt các chính sách bảo mật.

e. Code on demand

Một client không thể nói theo cách bình thường cho dù nó được kết nối trực

tiếp hay trung gian tới server. Những server trung gian có thể cải thiện khả năng

mở rộng của hệ thống bằng cách kích hoạt cân bằng tải (load-balancing) và cung

cấp chia sẻ bộ đệm. Chúng cũng có thể được cài đặt các chính sách bảo mật.

f. Uniform interface

Giao diện đồng nhất giữa client và server đơn giản hóa và tách riêng kiến trúc,

cho phép phát triển độc lập từng phần.

5. Cài đặt RESTful Web service với Java (JAX-RS) sử dụng Jersey

a. JAX-RS và jersey

Java hỗ trợ REST thông qua Java Specification Request 311(JSR). Công

nghệ này được gọi là JAX-RS (Java API for RESTful Web Services). JAX-

RS sử dụng các annotation xác định quan hệ giữa các lớp Java.

Jersey là các tham chiếu implementation cho công nghệ này. Về cơ bản

Jersey chứa một REST server và một REST client. Nhân client được cung

cấp một thư viện sử dụng để kết nối với server.

Về phía server, Jersey sử dụng một servlet quét các lớp đã được định nghĩa

trước đó để xác định tài nguyên RESTful. Thông qua tệp cấu hình web.xml

trong ứng dụng web , đăng kí servlet cung cấp bởi phân phối Jersey.



URL cơ bản của servlet:

http://your_domain:port/display-name/url-pattern/path_from_rest_class

Servlet phân tích các yêu cầu HTTP đến và lựa chọn các lớp và phương

thức chính xác để phản hồi. Lựa chọn này dựa trên các annotation trong

lớp và các phương thức.

b. JAX-RS annotations

Các annotations quan trọng trong JAX-RS

Annotation Mô tả

@PATH(your_path) Thiết lập đường dẫn cơ sở URL + your_path.

Đường dẫn cơ sở dựa và tên ứng dụng của bạn,

servlet và pattern từ tệp cấu hình web.xml

@POST Chỉ ra các phương thức sẽ trả lời cho một request

HTTP POST

@GET Chỉ ra các phương thức sẽ trả lời cho một request

HTTP GEST

@PUT Chỉ ra các phương thức sẽ trả lời cho một request

HTTP PUT

@DELETE Chỉ ra các phương thức sẽ trả lời cho một request

HTTP DELETE

@Produces - Xác định định dạng dữ liệu khi phương thức

xử lý và trả về

- Định dạng qui định là dạng có trong MIME

như text/plain, text/xml, application/xml,

hay text/json

- Áp dụng cho các phương thức @GET,



@POST, và @PUT

@Consumes - Xác định loại dữ liệu được gửi từ client

đến server cho xử lý trên server

- Các định dạng hỗ trợ text/plain, text/xml,

hay application/x-www-form-urlencoded (hỗ

trợ dạng phương thức POST)

- Áp dụng cho đầy đủ 4 phương thức của

RESTful

@PathParam Lấy giá trị từ URL trên đường dẫn sau ‘/’

c. Các bước để phát triển web servieces sử dụng RESTful với Java

Bước 1: Tạo Web Application

Bước 2: Đưa Restful Web Services vào trong Web Application

Bổ sung các thư viện hỗ trợ như JAX-RS 1.1 và Jersey

Bước 3: Định nghĩa và cài đặt các phương thức cho Web Services

Bước 4: Sử dụng annotation để định dạng cho các services được định nghĩa

trong bước 3

@Path host web service – root resource và sub resource

Loại HTTP methods dùng để truy vập

Lấy dữ liệu về hay cập nhật dữ liệu trên server @Produces hay

@Consumes

Bước 5: Build Web Services, deploy

Bước 6: Testing Web Services, phát sinh WSDL để sử dụng ở client

d. Demo đơn giản về RESTful webservice



o Yêu cầu:

Java

Netbeans IDE

GlassFish server

Jersey

- Lớp của ứng dụng

- Source của lớp “CalculatorResource ”

@Path("generic")

public class CalculatorResource {

@Context

private UriInfo context;

public CalculatorResource() {

}

@Path("/add")

@GET

@Produces("text/plain")

public String add(

@DefaultValue("5") @QueryParam("num1") double num1,

@DefaultValue("3") @QueryParam("num2") double num2) {



double result = num1+num2;

return ""+ result;

}

}

- Thực hiện test web services.

http://localhost:8080/Restful_Demo/webresources/generic/add

kết quả : 8.0

http://localhost:8080/Restful_Demo/webresources/generic/add?

num1=4&num2=10

kết quả 14.0

Tạo ứng dụng sử dụng web services đã viết ở trên


http://localhost:8080/Restful_Demo/webresources/generic/add?num1=4&num2=10

http://localhost:8080/Restful_Demo/webresources/generic/add?num1=4&num2=10

http://localhost:8080/Restful_Demo/webresources/generic/add


- Chỉnh sửa trang index.jsp tạo giao diện cho việc nhập liệu

- Tạo Servlet

@WebServlet(name = "CalculatorServlet", urlPatterns =

{"/CalculatorServlet"})

public class CalculatorServlet extends HttpServlet {

protected void processRequest(HttpServletRequest request,

HttpServletResponse response)



throws ServletException, IOException {

response.setContentType("text/html;charset=UTF-8");

PrintWriter out = response.getWriter();

try {

String action = request.getParameter("btAction");

String url =

"http://localhost:8080/Restful_Demo/webresources/generic";

if(action.equals("Add")){

String num1 = request.getParameter("txtNum1");

String num2 = request.getParameter("txtNum2");

Client client = Client.create();

client.setFollowRedirects(Boolean.TRUE);

WebResource resource = client.resource(url);

MultivaluedMap<String, String> params = new

MultivaluedMapImpl();

params.add("num1", num1);

params.add("num2", num2);

String res =

resource.path("add").queryParams(params).get(String.class);

out.println("Add: "+num1+ " + "+ num2 + "= "+res);

}

} finally {

out.close();



}

}

- Deploy ứng dụng

6. Đánh giá

- RESTful là một phương pháp mới để tạo web services sử dụng cách thức

đơn giản để trao đổi dữ liệu độc lập platform với hiệu suất khá cao.

- Khả năng uyển chuyển và đơn giản của RESTful khi xử lý bằng một client

khác ngôn ngữ.

- Đơn giản và nhẹ nhàng khi áp dụng web services để truyền dữ liệu từ client

đến server và truyền kết quả xử lý là một object từ server đến client



II. JavaScript Object Notation – JSON.

1. Khái niệm

JSON (JavaScript Object Notation) là một định dạng trao đổi dữ liệu hạng

nhẹ mà con người có thể đọc được và máy tính dễ dàng phân tích cú pháp được. Nó

dựa trên một tập hợp con của ngôn ngữ lập trình JavaScript, tiêu chuẩn ECMA-262

(3rd Edition - Tháng 12 năm 1999 ). JSON là một định dạng văn bản hoàn toàn độc

lập với ngôn ngữ, nhưng sử dụng quy ước mà đã quen thuộc với các lập trình viên

bao gồm C, C + +, C #, Java, JavaScript, Perl, Python, và nhiều ngôn ngữ khác

khác. Các tính chất này làm cho JSON trở thành một ngôn ngữ trao đổi dữ liệu lý

tưởng.

Douglas Crockford là người đầu tiên xác định và phổ biến các định dạng

JSON. JSON được sử dụng ở State Software, một công ty đồng sáng lập bởi

Crockford , bắt đầu từ khoảng năm 2001.

JSON được xây dựng trên hai cấu trúc:

Một tập hợp của các cặp tên / giá trị. Trong các ngôn ngữ khác nhau, điều

này được thực hiện như một object, record, struct, dictionary, hash table,

keyed list, hay associative array.

Một danh sách có thứ tự của các giá trị. Trong hầu hết các ngôn ngữ, điều

này được thực hiện như một array, vector, list, hay sequence

2. Đặc điểm

a. Data types, syntax and example

Các định dạng dữ liệu của JSON bao gồm: số(number), chuỗi(string), bollean,

mảng(array), object và null.

Cú pháp JSON là một tập hợp con của cú pháp đối tượng JavaScript.



Dữ liệu là các cặp tên/giá trị (name/values)

Dữ liệu được phân cách bằng dấu phẩy

Đối tượng nằm trong cặp ngoặc nhọn ‘{}’

Dấu ngoặc vuông giữ mảng ‘[]’

Dữ liệu JSON được viết trong cặp Tên/Giá trị. Một cặp Tên/Giá trị chứa tên

1 trường (trong dấu nháy đôi “”), theo sau là dấu phẩy, cuối cùng là giá trị:

"firstName" : "John"

Cú pháp này khá dễ hiểu, và tương đương với lệnh JavaScript sau:

firstName = "John"

b. Các giá trị của JSON

Giá trị (value) JSON có thể là:

1 số (nguyên (integer) hay số thực (floating point))

1 chuỗi (nằm trong dấu nháy đôi “”)

1 số luận lý (true or false)

1 mảng (nằm trong dấu ngoặc vuông [])

1 đối tượng (nằm trong dấu ngoặc nhọn {})

Kiểu null

Các đối tượng JSON

Các đối tượng được đặt trong dấu ngoặc nhọn {}.Đối tượng có thể chứa nhiều

cặp Tên/Giá trị (Name/Values):



{ "firstName":"John" , "lastName":"Doe" }

Và tương đương với lệnh JavaScript sau:

firstName = "John"

lastName = "Doe"

Mảng của JSON

Mảng JSON nằm trong dấu ngoặc vuông []. 1 mảng có thể chứa nhiều đối

tượng:

{

"employees": [

{ "firstName":"John" , "lastName":"Doe" },

{ "firstName":"Anna" , "lastName":"Smith" },

{ "firstName":"Peter" , "lastName":"Jones" }

]

}

Trong ví dụ trên, đối tượng “employees” là 1 mảng chứa 3 đối tượng. mỗi

đối tượng là 1 record của person (với 1 ‘first name và’ 1 ‘last name’).

c. JSON làm việc như thế nào

JSON sử dụng cú pháp JavaScript

Bởi vì JSON sử dụng cú pháp JavaScript, nên không cần 1 chương trình trung

gian làm việc giữ JSON và JavaScript. Với JavaScript bạn có thể tạo 1 mảng các



đối tượng và gán dữ liệu như sau:

var employees = [

{ "firstName":"John" , "lastName":"Doe" },

{ "firstName":"Anna" , "lastName":"Smith" },

{ "firstName":"Peter" , "lastName": "Jones" }

];

Dòng đầu tiên trong mảng đối tượng JavaScript có thể được truy cập như sau:

employees[0].lastName;

Kết quả:

Doe

Dữ liệu mới được gán như sau:

employees[0].lastName = "Jonatan";

Convert chuỗi JSON thành đối tượng JavaScript

Với JSON, để lấy dữ liệu JSON từ web server (như 1 file hay 1 HttpRequest),

convert dữ liệu JSON thành đối tượng JavaScript, và sử dụng dữ liệu này trong

trang web. Sau đây là demo:



Ví dụ JSON – Tạo Object từ Chuỗi (String):

Đầu tiên, tạo 1 chuỗi JavaScript chứa cú pháp JSON:

var txt = '{ "employees" : [' +

'{ "firstName":"John" , "lastName":"Doe" },' +

'{ "firstName":"Anna" , "lastName":"Smith" },' +

'{ "firstName":"Peter" , "lastName":"Jones" } ]}';

Kể từ khi cú pháp JSON là tập con của cú pháp JavaScript, hàm JavaScript

eval() có thể convert chuỗi JSON thành đối tượng JavaScript. Hàm eval() sử dụng

trình biên dịch(compiler) JavaScript sẽ phân tích cú pháp(parse) chuỗi JSON và

sinh ra đối tượng JavaScript. Chuỗi phải được bọc trong dấu ngoặc ‘()’ để tránh lỗi

cú pháp:

var obj = eval ("(" + txt + ")");

Cuối cùng là việc sử dụng đối tượng JavaScript trong trang web như sau:

<p>



First Name: <span id="fname"></span><br />

Last Name: <span id="lname"></span><br />

</p>

<script type="text/javascript">

document.getElementById("fname").innerHTML = obj.employees[1].firstName

document.getElementById("lname").innerHTML = obj.employees[1].lastName

</script>

JSON Parser

Sẽ an toàn hơn để sử dụng JSON Parser để convert chuỗi JSON thành đối tượng

JavaScript. Một JSON Parser sẽ nhận dạng chỉ chuỗi JSON và không biên dịch các

script khác.Trong trình duyệt có hỗ trợ mặc định cho JSON, thì JSON sẽ được

parse nhanh hơn. Thông thường thì các trình duyệt mới đều hỗ trợ mặc định cho

JSON và trong chuẩn ECMAScript (JavaScript) mới nhất.

3. Triển khai ứng dụng JSON

a. Phương pháp triển khai một ứng dụng JSON

Thực hiện một ứng dụng dùng JSON khá giống với sử dụng XML. Nhưng

như đã trình bày ở phần trên, JSON sử dụng cú pháp JavaScript, nên không cần 1

chương trình trung gian làm việc giữ JSON và JavaScript, nên việc truy xuất dữ

liệu JSON được tiến hành nhanh hơn và có vẻ dễ dàng hơn. Để xây dựng 1 ứng

dụng JSON, chúng ta cần thiết lập các phương thức mapping dữ liệu biểu diển bới



JSON với kiểu dữ liệu biểu diễn bởi các ngôn ngữ lập trình. VD sự tương ứng giữa

JSON và JAVA

Từ sự tương ứng ấy, lập trình viên sẽ thiết lập một parser để chuyển đổi các

đối tượng JSON. Ứng dụng sau sẽ cho thấy rõ điều này.

b. Demo ứng dụng

Dưới đây chúng tôi xin trình bày một ứng dụng demo đơn giản sử dụng JSON.

Ứng dụng tham khảo OpenSource tại http://code.google.com/p/json-simple/

Ứng dụng tuân thủ đúng các đặc điểm kỹ thuật của JSON và hầu như chưa

xuất hiện lỗi(qua quá trình test, 100% test case passed). Ứng dụng cung cấp rất

nhiều phương thức cho phép người dùng có thể encode, decode/parse và escape

JSON text. Ứng dụng được thực hiện trên Eclipse. Qua thực nghiệm ứng dụng cho

hiệu suất khá cao. Sau đây là phần giới thiệu ứng dụng.

Các lớp của ứng dụng:

- Package org.json.simple.element chứa các lớp mô tả các phương thức

chuyển đổi, thao tác trên từng kiểu dữ liệu JSON mô tả, mapping với các

kiểu dữ liệu Java


http://code.google.com/p/json-simple/


- Package org.json.simple.parser chứa các lớp và interface mô tả các phương

thức thực hiện nghiệp vụ chuyển đổi sử dụng trong các lớp ở Package



org.json.simple.element

Ví dụ Encoding JSON text

- Encode a JSON object

- Encode a JSON array



- Merge two JSON arrays



- Combination of JSON primitives, JSON object and JSON arrays



Ví dụ decoding JSON text

- Convenient way: Use JSONValue



Kết quả

- Container factory



Kết quả

- Escaping text that contains special characters



4. JSON và XML. Đánh giá ưu nhược điểm

a. JSON và UML

Giống như XML

JSON là văn bản trơn (không có định dạng(màu sắc, cỡ chữ,…))

JSON là "tự mô tả" (người dùng có thể hiểu được)

JSON là phân cấp (có cấu trúc cây)

JSON có thể được phân tích cú pháp (parse) bởi JavaScript

Dữ liệu JSON có thể được truyền đi bằng AJAX

Không giống như XML

Không có thẻ kết thúc

Ngắn hơn

Nhanh hơn để đọc và ghi



Có thể được phân tích cú pháp bằng hàm dựng sẵn trong JavaScript là

eval()

Sử dụng mảng (Array)

Không dùng các từ reserve

Tại sao dùng JSON?

JSON nhanh hơn XML trong xử lý dữ liệu, cụ thể như sau:

Sử dụng XML

Lấy một tài liệu XML

Sử dụng XML DOM để lặp qua tài liệu

Trích xuất các giá trị và lưu trữ trong các biến

Sử dụng JSON

Lấy một chuỗi JSON

Dùng hàm eval () chuyển chuỗi JSON thành đối tượng JavaScript

Đánh giá về JSON, Douglas Crockford - tác giả của JSON có một số

đánh giá bác bỏ các luận điểm so sánh JSON với XML như sau:

JSON không có không gian tên . Tuy nhiên, tất cả các đối tượng là một

không gian tên. Thiết lập của nó của các phím là độc lập với tất cả các đối

tượng khác. Ngoài ra, JSON sử dụng ngữ cảnh để tránh sự mơ hồ, giống như

ngôn ngữ lập trình.

JSON không có Validator. Tất cả các ứng dụng phỉa tự chịu trách nhiệm

kiểm tra đầu vào của nó. Điều này không thể được ủy thác. Một validator

YAML có thể được sử dụng.

JSON là không phải là mở rộng . Điều đó là không cần thiết. JSON khá

linh hoạt. Nó có thể đại diện cho bất kỳ cấu trúc dữ liệu không truy hồi



JSON là không phải là XML . Douglas cho rằng JSON là đơn giản hơn

nhiều hơn so với XML.

b. Đánh giá ưu nhược điểm

Ưu điểm

- Xử lý dữ liệu nhanh hơn UML

- Hỗ trợ Unicode nên có thể biểu diễn nhiều ngôn ngữ

- JSON tiết kiệm dung lượng hơn XML do bản thân XML đòi hỏi một số cú

pháp nhất định về thẻ mở thẻ đóng gây hao tốn về dung lượng.

- Dữ liệu trả về dạng object nên có thể sử dụng ngay

Nhược điểm

- JSON không sử dụng các thẻ như XML nên việc định dạng khó khăn

- JSON mới xuất hiện không phổ biến như XML

- Trong Flash, Parsing JSON trong Flash Player chậm hơn so với XML do các

class xử lý JSON được viết ngoài chứ không thuộc loại Instinctive class như

XML

- XML về cái nhìn rõ ràng và dễ nắm bắt hơn JSON. Do đó trong quá trình

làm việc giữa các lập trình viên XML dễ hiểu, dễ trao đổi hơn. Tất nhiên đây

chỉ là đặc điểm liên quan đến con người.



Tham khảo

[1]. http://www.ibm.com/developerworks

[2]. http://www. en.wikipedia.org

[3]. http://www.qhonline.info/forum/showthread.php/4373-json-la-gi-json-

lam-viec-nhu-the-nao-phan-1

[4]. http://kieutrongkhanh.net/index.php/java-web-service-x/79-gii-thiu-v-

restful-web-services

[5]. http://www.json.org/


http://www.json.org/

http://kieutrongkhanh.net/index.php/java-web-service-x/79-gii-thiu-v-restful-web-services

http://kieutrongkhanh.net/index.php/java-web-service-x/79-gii-thiu-v-restful-web-services

http://www.qhonline.info/forum/showthread.php/4373-json-la-gi-json-lam-viec-nhu-the-nao-phan-1

http://www.qhonline.info/forum/showthread.php/4373-json-la-gi-json-lam-viec-nhu-the-nao-phan-1

http://www.en.wikipedia.org/

http://www.ibm.com/developerworks

congngheweb cd23 restful&json phamchienthang nguyenmanhhoang

Documents