SOAP – Simple Object Access Protocol

SOAP – Một tiêu chuẩn của W3C, là giao thức sử dụng XML để định nghĩa dữ liệu dạng thuần văn bản (plain text) thông qua HTTP. SOAP là cách mà Web Service sử dụng để truyền tải dữ liệu. Vì dựa trên XML nên SOAP là một giao thức không phụ thuộc platform cũng như bất kì ngôn ngữ lập trình nào.

Một thông điệp SOAP được chia thành hai phần là header và body. Phần header chỉ ra địa chỉ Web Service, host, Content-Type, Content-Length tương tự như một thông điệp HTTP.

Khi tạo một dự án Web Service, mặc định Web Visual Develop sẽ tạo cho bạn phương thức HelloWorld() sau:

public string HelloWorld()
{
    return "Hello World";
}

Một HTTP Request sẽ có dạng sau:

POST /MathService.asmx/HelloWorld HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: length

RESTful Web services

REST định nghĩa các quy tắc kiến trúc để bạn thiết kế Web services chú trọng vào 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 số 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 vài năm qua như là một mô hình thiết kế dịch vụ chiếm ưu thế. Trong thực tế, REST đã có những ảnh hưởng lớn và gần như thay thế SOAP và WSDL vì nó đơn giản và dễ sử dụng hơn rất nhiều.

REST không thu hút được nhiều sự chú ý khi lần đầu tiên giới thiệu vào năm 2000 bởi Roy Fielding trong luận án của ông "Architectural Styles and the Design of Network-based Software Architectures" (Phong cách kiến trúc và thiết kế kiến trúc phần mềm dựa trên mạng) tại Đại học California. Luận án đã phân tích một loạt các nguyên tắc kiến trúc phần mềm sử dụng Web như là một nền tảng tính toán phân tán (xem Tài nguyên liên kết tới luận án). Đến nay, vài năm sau đó, đã xuất hiện các framework chủ đạo cho REST và chúng vẫn đang được tiếp tục phát triển, nó đang được xem xét để đưa vào trong bộ Java™ 6 thông qua tiêu chuẩn JSR-311.

Bài viết này chỉ ra rằng khi REST được biết đến nhiều hơn thì việc cụ thể hóa một Web service REST sẽ tuân thủ theo bốn nguyên tắc thiết kế cơ bản sau:

Sử dụng các phương thức HTTP một cách rõ ràng
Phi trạng thái
Hiển thị cấu trúc thư mục như URls
Chuyển đổi JavaScript Object Notation (JSON) và XML hoặc cả hai.

Các phần sau đây sẽ mở rộng dựa trên bốn nguyên lý này và đề xuất một nhân tố kỹ thuật cơ bản giải thích vì sao chúng quan trọng đối với các nhà thiết kế dịch vụ mạng REST.

Về đầu trang

Sử dụng các phương thức HTTP một cách rõ ràng

Một đặc tính quan trọng của dịch Web service RESTful là sử dụng một cách rõ ràng các 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 được sử dụng có chủ đích bởi các ứng dụng người dùng để thu thập tài nguyên, dữ liệu từ một máy chủ, hoặc thực thi một truy vấn mà máy chủ sẽ tìm kiếm và phản hồi cùng với một gói thông tin tương thích.

REST yêu cầu các nhà 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 hành động tạo, đọc, cập nhật và xoá (CRUD) các quá trình vận hành và các phương thức HTTP. Theo cách ánh xạ này thì:

Để tạo một tài nguyên trên máy chủ, bạn cần sử dụng phương thức 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 lỗ hổng trong thiết kế vốn có trong các Web API là việc sử dụng các phương thức HTTP mà không có mục đích 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, phương thức GET-yêu-cầu-URI đã không được sử dụng đúng đắn hoặc chưa sử dụng đầy đủ. Nếu Web API sử dụng GET để tiến hành các thủ tục ra lệnh từ xa thì 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 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 thức yêu cầu HTTP GET 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 (trong ví dụ này) là để tạo thêm một người dùng mới vào kho dữ liệu. Vấn đề ở đây chỉ về mặt ngữ nghĩa. Các Web server được thiết kế để phản hồi lại các yêu cầu HTTP GET bằng cách truy vấn dữ liệu phù hợp với đường dẫn (hoặc câu truy vấn) theo URI và phản hồi những dữ liệu này hoặc những thông tin đại diện, chứ không phải để thêm một dữ liệu vào database. Từ góc độ mục đích sử dụng giao thức đó và theo tiêu chuẩn Web server HTTP/1.1 thì việc sử dụng GET theo cách này tồn tại mâu thuẫn.

Về mặt ngữ nghĩa, có nhiều vấn đề khi sử dụng 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ó dùng các công cụ Web cache (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 thông qua đường dẫn. Một cách đơn giản để vượt qua vấn đề hay xảy ra này là di chuyển tên và giá trị các tham số yêu cầu trên URI vào 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 URI 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 yêu cầu RESTful: 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 tài nguyên phụ đượ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 cha, như đã xác định trong yêu cầu POST, tương tự như cách tệp đã thuộc thư mục cha. Máy khách thiết lập quan hệ giữa thực thể và nhánh cha, 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ị.

Tương tự, những thay đổi của phương thức Web 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. Thực hiện lệnh Cập nhật thông qua HTTP GET

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

Câu lệnh này thay đổi thuộc tính (hoặc đặc tính) name của dữ liệu. Có thể dùng chuỗi truy vấn (query) để dùng cho những thao tá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ó thể không hoạt động khi sử dụng đối với các thao tác phức tạp hơn. Do mục tiêu của chúng ta là làm rõ việc sử dụng các phương thức HTTP, nên 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 đổi dữ liệu gốc, cho thấy cách làm rõ ràng hơn, phù hợp với các nguyên lý của REST và các khái niệm của các phương thức HTTP. Lệnh PUT trong ví dụ 5 rõ ràng ở chỗ nó chỉ ra dữ liệu đượ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 dữ liệu cầ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 các 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 Web service RESTful, các động từ — POST, GET, PUT, và DELETE — đã được định nghĩa bởi giao thức. Và tốt nhất, để giữ giao diện được khái quát hoá và cho phép người dùng hiểu rõ các thao tác mà họ gọi thì Web service không nên đưa ra nhiều động từ hoặc các thủ tục remote 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 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 hay thủ tục remote từ xa.

JSON

Chủ Nhật, 5 tháng 10, 2014