Ghi chú của Biên tập: Phiên bản IBM® WebSphere® sMash và IBM WebSphere sMash Developer Edition dựa trên dự án vườn ươm Project Zero rất được hoan nghênh. Project Zero là cộng đồng phát triển WebSphere Smash và sẽ tiếp tục cung cấp cho các nhà phát triển một nền tảng miễn phí để phát triển các ứng dụng với các kiến trúc mới nhất, tính năng mới nhất, và sự hỗ trợ của cộng đồng.

Trước khi bạn bắt đầu

Bài viết này giả định rằng bạn đã tải về Project Zero và đã hoặc đọc xong bài hướng dẫn (nhập môn) hoặc đã tự mình viết một ứng dụng đơn giản. Bạn cũng cần phải làm quen với bài hướng dẫn Tạo một giao diện WSDM cho một máy chủ HTTP bằng cách sử dụng Muse Apache (Create a WSDM interface for an HTTP server using Apache Muse), trên developerWorks, trong đó chỉ ra cách làm thế nào để tạo ra một giao diện quản lý cho một máy chủ HTTP bằng cách sử dụng Apache Muse và các đặc tả WS-*. Bài viết này không yêu cầu bạn phải là một người sử dụng thành thạo về công nghệ Muse hay WS-*, chỉ cần bạn hiểu được vấn đề mà hướng dẫn này đã cố gắng giải quyết và mã đã cung cấp những đặc tính nào.

Giới thiệu

Bài viết này không phải là để liệt kê các lý lẽ tán thành và phản đối công nghệ WS-* so với công nghệ hướng-REST và nó không phải để chọn ra một "người chiến thắng". Mục đích của bài viết này là để giải thích REST và các kỹ thuật phát triển Web 2.0 có cung cấp được một giải pháp thay thế có hiệu quả cho các dự án quản lý các hệ thống và hy vọng đem lại cho các nhà phát triển một số lựa chọn bổ sung thêm hay không. Những người sử dụng WS-* và những người sử dụng REST đang có một cuộc tranh luận về kỹ thuật nào thích hợp nhất cho các tập hợp vấn đề gì, trong đó những người sử dụng WS-* thường xuyên kêu ca rằng các bài toán phức tạp, mức doanh nghiệp, không thể giải quyết được hoàn toàn bằng REST (RESTfully).

Điểm lại: giao diện WSDM của chúng ta dành cho các máy chủ HTTP

Giao diện dịch vụ web ban đầu mà chúng ta đã tạo ra để quản lý các máy chủ sử dụng HTTP sử dụng một tài liệu WSDL 1.1 để trưng ra một bộ các thuộc tính và các hoạt động. Các thuộc tính là các cặp tên-giá trị có thể được truy cập bằng cách sử dụng các hoạt động định nghĩa bởi đặc tả WS-Các thuộc tính tài nguyên (WS-ResourceProperties - WS-RP). Một số các thuộc tính thực tế đã được định nghĩa bởi các đặc tả WS-* (ví dụ như WS-Quản lý phân tán (WS-DistributedManagement hay WSDM)) trong khi các thuộc tính khác đã được tùy chỉnh theo các tài nguyên máy chủ HTTP của chúng ta. Danh sách đầy đủ các thuộc tính mà chúng ta đã sử dụng như sau:

• ResourceId (WSDM)
• ManageabilityCapability (WSDM)
• Description (WSDM)
• Caption (WSDM)
• Version (WSDM)
• OperationalStatus (WSDM)
• Name (custom)
• Port (custom)
• ThreadsPerChild (custom)

Các hoạt động được đưa vào trong giao diện của chúng ta là từ WS-RP và phát triển xung quanh việc đọc và viết một hoặc nhiều giá trị thuộc tính. Chúng ta cũng đã có hai hoạt động tùy chỉnh có tên là Khởi động (Start) và Dừng (Stop) đã được sử dụng để khởi động và dừng các máy chủ HTTP. Tất cả các hoạt động WS-RP đã được khung công tác Muse Apache cung cấp, trong khi các hoạt động tùy chỉnh đã được triển khai thực hiện với mã Java™ và được đưa vào bằng cách sử dụng các điểm mở rộng Apache Muse. Danh sách đầy đủ các hoạt động mà chúng ta đã sử dụng như sau:

• GetResourceProperty (WS-RP)
• GetResourcePropertyDocument (WS-RP)
• GetMultipleResourceProperties (WS-RP)
• Start (custom)
• Stop (custom)

Bạn có thể nhớ lại rằng chúng ta đã không đưa vào bất kỳ các hoạt động "viết" nào từ WS-RP bởi vì chúng ta không có bất cứ các thuộc tính nào mà chúng ta muốn nó thay đổi trực tiếp. Một số trong các thuộc tính có thể thay đổi được, nhưng chỉ như là một tác động phụ (ví dụ, thuộc tính OperationalStatus có thể thay đổi khi máy chủ đã được khởi động hoặc được dừng lại).

Ánh xạ WS-ResourceProperties tới REST

Việc lập trình RESTful dựa trên các quy tắc và các quy ước của mức vận chuyển trên mạng (thường là HTTP) và một số các định dạng dữ liệu nổi tiếng (thường là XML hoặc JSON). Để trưng ra những thông tin đã có trong các tài liệu các thuộc tính tài nguyên của chúng ta theo kiểu cách RESTful, chúng ta sẽ sử dụng phương thức GET của HTTP, để lấy ra một đối tượng JSON có các trường (các cặp tên- giá trị) tương tự với các thuộc tính tài nguyên của chúng ta. Nói cách khác, chúng ta đang thay thế tài liệu các thuộc tính tài nguyên bằng một đối tượng JSON và sử dụng các phương thức HTTP thay cho các phương thức WS-RP. Liệt kê 1 hiển thị một biểu diễn JSON của tài nguyên máy chủ HTTP của chúng ta sẽ có thể như thế nào:

                
{
  "name": "server1.ibm.com", 
  "port": 8080, 
  "threads": 250, 
  "admin": "admin@us.ibm.com"
}
      

Bạn có thể nhận thấy rằng các thuộc tính WSDM không có mặt trong biểu diễn JSON của chúng ta. Một số khái niệm WS-* không thể chuyển dịch thành một thiết kế RESTful hoặc có mặt trong các lĩnh vực khác của ứng dụng. Ví dụ, thuộc tính ResourceId WSDM và mẫu tài nguyên kéo theo nó là không cần thiết; thay vì định nghĩa tài nguyên bằng cách sử dụng các tham chiếu điểm cuối (endpoint references) các giá trị ResourceId, chúng ta sẽ sử dụng các mẫu URI và buộc tất cả các tài nguyên phải có một URI duy nhất. Bằng cách sử dụng lại HTTP cho một phần của giao diện tài nguyên của chúng ta, chúng ta đang loại bỏ nhu cầu cần một số các thuộc tính và các hoạt động (những người sử dụng WS-* có thể chỉ ra rằng chúng ta đang tự mình hạn chế chỉ dùng HTTP, nhưng tranh luận về liệu việc đó là tốt hay xấu là vượt ra ngoài phạm vi của bài viết này). Chúng ta cũng sẽ sử dụng các URI mô tả và cung cấp tài liệu con người đọc được về các dịch vụ của chúng ta tương phản với một số các thuộc tính mô tả đã được nhúng vào trong tài liệu WSDL. Kết quả cuối cùng là biểu diễn JSON của chúng ta là đầy đủ đến mức như chúng ta cần, căn cứ vào việc bây giờ chúng ta có một giải pháp hướng HTTP.

Để làm cho các tài nguyên máy chủ HTTP trở nên dễ dàng khám phá và thao tác, chúng ta sẽ sử dụng một mẫu URI có dạng /httpd/{serverName} để phân biệt chúng. URI /httpd sẽ tham chiếu đến sưu tập của tất cả các máy chủ HTTP mà ứng dụng quản lý và URI /httpd/{serverName} sẽ tham chiếu đến một máy chủ HTTP riêng biệt. Các yêu cầu gửi đến sưu tập URI sẽ được tính toán đối với toàn bộ sưu tập (nếu có thể) trong khi yêu cầu được gửi đến một URI máy chủ riêng biệt sẽ chỉ hạn chế tới máy chủ mà nó biểu diễn. Bảng 1 cho thấy API REST sẽ mô tả các tài nguyên máy chủ HTTP của chúng ta:

Nếu có lúc nào đó chúng ta muốn tăng thêm giao diện của chúng ta để cho phép những người sử dụng chỉnh sửa trực tiếp các thuộc tính này, chúng ta sẽ sử dụng phương thức PUT của HTTP thay vì SetResourceProperties của WS-RP. Các mẫu URI của các yêu cầu PUT sẽ giống như các mẫu URI cho GET, với sự khác biệt chủ yếu là các yêu cầu PUT gửi dữ liệu JSON trong khi yêu cầu GET để nhận chúng.

Ánh xạ các hoạt động tùy chỉnh tới REST

Các hoạt động tùy chỉnh Start và Stop đặt ra một thách thức lớn hơn với ban thiết kế. Chúng ta chỉ có thể làm việc với bốn phương thức HTTP (GET, PUT, POST và DELETE) và việc nhúng các tên của hoạt động trong các yêu cầu PUT và POST được coi là một hình thức không tốt trong địa hạt REST. Để tránh vấn đề này, chúng ta cần phải thay đổi cách nghĩ về hành động khởi động và dừng máy chủ; thay vì nghĩ về nó như một hành động đối với bản cài đặt máy chủ HTTP, chúng ta sẽ nghĩ về nó như việc tạo ra hay phá hủy một tiến trình của máy chủ HTTP. Đây không phải là một sự nối dài thêm vì chính xác đó là cách hệ điều hành của bạn xử lý các yêu cầu khởi động và dừng: nó tạo ra một tiến trình có thể giám sát được và (cuối cùng) kết thúc được. Chúng ta sẽ tạo ra một tài nguyên tiến trình của máy chủ HTTP với một tập hợp các URI của riêng nó và các ngữ nghĩa HTTP của riêng nó. Bảng 2 cho thấy API REST cho kiểu tài nguyên mới này:

Như bạn có thể thấy, tài nguyên tiến trình HTTP không có biểu diễn JSON — nó chỉ là một URI. Việc gửi một POST HTTP đến URI sẽ tạo ra một tiến trình ("khởi động máy chủ"), trong khi DELETE HTTP sẽ hủy tiến trình ("dừng máy chủ") và GET HTTP sẽ cung cấp trạng thái (tương tự với thuộc tính OperationalStatus của WSDM, mà chúng ta không cần nữa). Việc phân chia giao diện của chúng ta thành hai kiểu tài nguyên riêng biệt đã cho phép chúng ta đạt được cùng một chức năng mà không cần dùng đến RPC hay các kỹ thuật theo phong cách WS-*. Trong phần kế tiếp, chúng ta sẽ xem xét làm thế nào để chuyển quyết định thiết kế này thành mã lệnh thực, hoạt động được.

Thực hiện Quản lý Máy chủ HTTP bằng Zero

Việc viết mã để triển khai thực hiện các giao diện RESTful mà chúng ta tạo ra trong phần vừa qua sẽ khá dễ dàng, đặc biệt là nếu bạn đã hiểu việc triển khai thực hiện dựa trên Muse từ các hướng dẫn trước. Đối với dự án này, chúng ta sẽ sử dụng kịch bản lệnh Groovy thay cho các lớp Java, các chú thích RESTdoc thay cho các tệp tin WSDL và JSON thay cho XML.

Truy cập máy chủ HTTP Apache bằng Groovy

Trước khi bạn bắt đầu viết mã, cần phải chắc chắn rằng bạn có máy chủ HTTP Apache (httpd) đã cài đặt và làm việc đúng. Nếu bạn không hoàn thành hướng dẫn trước và chưa cài đặt httpd, phần Tài nguyên có một liên kết đến các trang Web Apache ở đó bạn có thể tải xuống máy chủ và các hướng dẫn cài đặt của nó. Hãy chắc chắn rằng bạn đã cài đặt máy chủ như một dịch vụ (hay daemon – N.D: một trình tiện ích hoạt động ngầm trong nền sau); nếu bạn không chắc chắn liệu bạn có một dịch vụ hay không, chỉ cần gõ httpd -k install vào dòng lệnh và các dịch vụ sẽ được tạo ra nếu nó chưa có. Việc có httpd được cài đặt như một dịch vụ sẽ cho phép chúng ta khởi động và dừng máy chủ không đồng bộ từ mã của chúng ta.

Với httpd được cài đặt và sẵn sàng sử dụng, chúng ta cần phải tạo ra một dự án Zero để chứa mã của chúng ta. Sử dụng dòng lệnh trong Liệt kê 2 để tạo ra một dự án có tên là zero.httpd; theo mặc định, dự án sẽ chứa các phụ thuộc vào Zero Core và công cụ RESTdoc và đó là tất cả những thứ mà chúng ta cần cho mã mà chúng ta đang viết trong bài viết này. Nếu bạn muốn nhảy lên phía trước và xem dự án đã hoàn thành, bạn có thể tải nó từ phần Tải về.

                
$ zero create zero.httpd
      

Trước khi chúng ta có thể viết bất kỳ mã lệnh nào, chúng ta cần phải quyết định làm thế nào để mã sẽ tìm thấy các bản cài đặt httpd để cho nó có thể đọc các tệp của chúng và thi hành các lệnh đối với chúng. Trong phần hướng dẫn trước, chúng ta sử dụng các tệp tin muse.xml để tạo các tham số khởi tạo có chứa các đường dẫn cài đặt httpd. Chúng ta sau đó có thể tạo các đường dẫn đến tệp tin httpd mà không cần phải viết thành mã lệnh chết cứng các dữ liệu cài đặt httpd trong các tệp mã nguồn Java của chúng ta. Chúng ta sẽ tiến hành một cách tiếp cận tương tự với Zero, lúc này sử dụng tệp tin zero.config của nó để tạo ra một ánh xạ đặt tương ứng các tên máy chủ tới các thư mục cài đặt; một tên máy chủ có thể là bất kỳ mã nhận dạng ID gồm các ký tự chữ-số nào và sẽ được sử dụng để tạo ra các URI cụ thể cho các tài nguyên máy chủ HTTP. Liệt kê 3 cho thấy một tệp tin mẫu zero.config mà bạn có thể sử dụng như là một điểm khởi đầu:

                
[/config/httpd/servers[]]
server1=/httpd/server1
buildServer=/dev/builds/httpd
intranetSite=/public/prod/apache
    
[/config/http]
port=9080
  

Trong Liệt kê 3, các tên máy chủ của chúng ta được nhấn mạnh bằng chữ in đậm. Chúng ta sẽ có thể truy cập tập hợp các cặp tên-giá trị này trong mã Groovy của chúng ta bằng cách sử dụng bối cảnh toàn cục Zero. Để đơn giản hơn, chúng ta sẽ sử dụng server1 cho tất cả các thử nghiệm của chúng ta. Bạn nên thay đổi giá trị của đường dẫn cài đặt của server1 thành đường dẫn mà bản cài đặt httpd tại máy của bạn sử dụng. Bạn không cần hai mục của máy chủ khác — chúng ở đó chỉ để minh họa khuôn dạng cấu hình của chúng ta.

Trước khi bạn lưu và đóng lại tệp tin zero.config của bạn, nên thêm vào cùng một mục cho /config/http/port được hiển thị trong Liệt kê 3. Mục này sẽ được ghi đè lên cổng mặc định 8080 của Zero với giá trị 9080; httpd cũng có một cổng mặc định là 8080 và chúng ta không muốn có bất kỳ xung đột nào giữa ứng dụng Zero của chúng ta và các tiến trình httpd.

Bây giờ bạn sẽ tạo ra ba tệp: httpd.groovy, process.groovy và process.bnd và thêm chúng vào thư mục /app/resources của dự án. Hai tệp tin đầu tiên là các kịch bản lệnh Groovy sẽ đại diện cho hai tài nguyên RESTful được mô tả trong phần trước. Tệp tin thứ 3 sẽ được sử dụng để đặt cấu hình các mẫu URI được các tài nguyên cho phép.

Hãy bắt đầu với nhiệm vụ dễ nhất: tệp tin process.bnd. Bạn chỉ cần thêm một dòng vào tệp tin này và nó được hiển thị trong Liệt kê 4. Dòng này báo cho Zero đang chạy thi hành rằng nó cần cho phép mẫu URI /httpd/{id}/process mà chúng ta đã giải thích trong các bảng REST của chúng ta. Không có dòng này, Zero sẽ cho phép các yêu cầu đối với /httpd/{id} và /process/{id}, nhưng không bao giờ cho phép đối với /httpd/{id}/process.

                
httpd/process
      

Tệp tin httpd.groovy biểu diễn bản cài đặt httpd của chúng ta và yêu cầu hai phương thức: onList() và onRetrieve(). Phương thức thứ nhất sẽ trả về một danh sách các bản cài đặt httpd được ứng dụng Zero này quản lý và phương thức sau sẽ trả về một biểu diễn JSON của một bản cài đặt httpd riêng lẻ. Giao diện của chúng ta hiện không hỗ trợ sửa đổi từ xa các bản cài đặt httpd, do đó chúng ta không cần bất kỳ phương thức RESTful khác nào (onCreate() và v.v).

Liệt kê 5 hiển thị mã cho onList() và onRetrieve(). Mã thực hiện onRetrieve() có sử dụng một phương thức có tên là readConfig() để phân tích cú pháp các tệp tin httpd.conf; mã phân tích cú pháp của phương thức này được sao chép từ hướng dẫn trước và được sửa đổi chút ít để sử dụng một cú pháp kiểu Groovy hơn. Bạn có thể thấy mã thực hiện readConfig() bằng cách tải về dự án mẫu đã hoàn thành và xem /app/resources/httpd.groovy.

                
def onList()
{
    request.view = "JSON";
    request.json.output = config.httpd.servers[0].keySet();
    render();
}

def onRetrieve()
{
    def serverConfig = readConfig();
        
    if (serverConfig.isEmpty())
    {
        request.status = 404;
        return;
    }
        
    request.view = "JSON";
    request.json.output = [
        name: serverConfig.ServerName, 
        port: serverConfig.Listen, 
        threads: serverConfig.ThreadsPerChild, 
        admin: serverConfig.ServerAdmin
    ];
    render();
}
      

Liệt kê 5 cho thấy rằng chúng ta chọn ra các thuộc tính cấu hình httpd mà chúng ta muốn trưng ra khi chúng ta tạo ra dữ liệu đáp ứng JSON. Cũng như trong phiên bản WS-*, chúng ta có thêm nhiều tên gọi chung hơn cho các thuộc tính (để cho giao diện đó không phải là đặc thù-Apache) và chúng ta bỏ qua những cái nhạy cảm theo quan điểm an ninh. Ngoài ra cần lưu ý rằng chúng ta sử dụng một mã trạng thái HTTP đơn giản (404) để báo hiệu khi một máy chủ không tồn tại — không có các kiểu lỗi hay các thông báo bổ sung để gửi kèm. Phương thức onRetrieve() về khái niệm là tương tự với GetResourcePropertyDocument của WS-RP, nhưng không có lược đồ nào để xác nhận tính hợp lệ các kết quả và "các lỗi" được định nghĩa bởi lớp vận chuyển (HTTP), chứ không phải lớp ứng dụng.

Với các tài nguyên cài đặt httpd của chúng ta được định nghĩa, chúng ta có thể chuyển sang các tài nguyên tiến trình httpd. Liệt kê 6 hiển thị một triển khai thực hiện của process.groovy; nó rất đơn giản bởi vì kiểu tài nguyên này chỉ được sử dụng để khởi động máy chủ, dừng máy chủ và kiểm tra sự tồn tại của một tiến trình httpd. Bám theo các nguyên lý thiết kế REST phổ biến, chúng ta sẽ sử dụng POST HTTP để tạo ra một tiến trình httpd (khởi động máy chủ), DELETE HTTP để hủy một tiến trình httpd (dừng máy chủ) và GET HTTP để xác định xem máy chủ có đang chạy không. Các ba hoạt động này tương ứng với các phương thức onCreate(), onDeleteCollection() và onList(), theo trình tự.

                
def onCreate()
{
    Runtime.getRuntime().exec("${getServerHome()}/bin/httpd -k start");    
    request.status = 201;
}

def onDeleteCollection()
{
    Runtime.getRuntime().exec("${getServerHome()}/bin/httpd -k stop");
    request.status = 204;
}

def onList()
{
    def pidFile = new File(getServerHome(), "logs/httpd.pid");
        
    if (!pidFile.exists())
        request.status = 404;
}
      

Các phương thức onCreate() và onDeleteCollection() sử dụng cùng một mã mà tôi đã sử dụng trong hướng dẫn trước đây để khởi động và dừng các máy chủ: cụ thể, các phương thức này sử dụng API Runtime.exec() của JDK để nạp các tệp thực thi httpd và thi hành lệnh thích hợp. Điều này là chính xác đúng như các hoạt động tùy chỉnh Start và Stop trong giao diện WS-* của chúng ta. Phương thức onList() sử dụng lợi thế là thực tế httpd tạo ra một tệp tin mã nhận dạng (ID) tiến trình (hay PID) mỗi khi nó khởi động và kiểm tra sự tồn tại của nó để xác định xem máy chủ đang chạy hay không; nếu các tệp tin PID không tồn tại, phương thức trả về 404 Not Found thay cho 200 OK bình thường. Một lần nữa, bạn có thể nhận được tệp tin process.groovy đầy đủ bằng cách tải về dự án mẫu.

Ở thời điểm này, chúng ta đã triển khai thực hiện xong một API RESTful cho httpd, nhưng chúng ta không có cách để thử nghiệm nó dễ dàng. Trong phần kế tiếp, chúng ta sẽ tạo ra một số tài liệu RESTful cho phương thức Groovy của chúng ta và sử dụng công cụ RESTdoc để kiểm thử API của chúng ta mà không phải viết bất kỳ mã nào. Trong thực tế, bạn sẽ có thể kiểm tra các hoạt động mà mã của bạn đang có trên httpd mà không cần rời khỏi trình duyệt của bạn!

Trưng ra các API REST bằng RESTdoc

Trong phần vừa qua, chúng ta đã viết rất nhiều mã, nhưng chúng ta không giải thích nó. Khi nói đến các kịch bản lệnh RESTful của Zero, tài liệu hướng dẫn tốt, không chỉ giúp bạn nhớ mã của bạn hoạt động như thế nào, nó có thể giúp các lập trình viên phía-khách tạo ra và kiểm thử mã trình khách của họ. Bạn có thể viết các chú thích kiểu JavaDoc cho Groovy và các phương thức PHP của bạn và để cho công cụ RESTdoc của Zero tạo ra các bảng REST và các trang kiểm thử dành cho chúng (để biết thêm về nền tảng RESTdoc, xem Tài nguyên). Chúng ta sẽ bổ sung thêm các chú thích RESTdoc cho các kịch bản lệnh Groovy để có thể thử nghiệm giao diện httpd của chúng ta.

Liệt kê 7 hiển thị các chú thích RESTdoc cho tệp tin httpd.groovy; các mã thực hiện phương thức đã được gỡ bỏ cho ngắn gọn. Bạn có thể xem các chú thích RESTdoc cho cả hai kịch bản lệnh bằng cách tải về dự án mẫu. Các chú thích httpd.groovy minh họa rõ nhất vì chúng cho thấy tất cả các thẻ có khả năng được sử dụng trong các chú thích RESTdoc.

                
/**
 *
 * @success 200 Returns a list of server names that can be used to build server URIs.
 * @format text/json
 * @example
 * [
 *   "server1", 
 *   "server2",
 *   ...
 * ]
 *
 */
def onList()
{
    ...
}

/**
 *
 * @success 200 Returns the configuration data for the given server name.
 * @error 404 If there is no server associated with the given name.
 * @format text/json
 * @example
 * {
 *    "name": "server1.ibm.com", 
 *    "port": 8080, 
 *    "threads": 250, 
 *    "admin": "admin@us.ibm.com"
 * }
 *
 */
def onRetrieve()
{
    ...
}
      

Với các chú thích RESTdoc đã sẵn sàng, bạn có thể khởi động ứng dụng Zero (gõ zero run) và chuyển hướng tới http://localhost:9080/resources/docs trong trình duyệt của bạn. Bạn sẽ thấy một trang index có liệt kê tất cả các loại tài nguyên RESTful trong ứng dụng của bạn, trong số đó có httpd và tiến trình. Nhấn vào liên kết httpd và bạn sẽ thấy một trang giống như trong Hình 1. Trang này hiển thị tất cả các mẫu URI có thể được sử dụng để thao tác kiểu tài nguyên và các thông tin cần thiết cho các mã xử lý các yêu cầu và các đáp ứng.

Kiểm thử các API REST bằng RESTdoc

Việc kiểm thử các API RESTful của chúng ta có thể được thực hiện bằng cách sử dụng chính các trang có mô tả chúng. Từ trang RESTdoc httpd, hãy nhấp vào /httpd, đó là mẫu URI đầu tiên. Bạn sẽ thấy một hộp thoại được hiển thị trong Hình 2. Mẫu URI này không có các biến, do đó tất cả những gì mà bạn phải làm là nhấn vào nút Gửi (Send) và bạn sẽ thấy một đáp ứng bao gồm một danh sách các tên máy chủ — chính là các tên máy chủ mà bạn đặt vào tệp tin zero.config. Hình 3 cho thấy đáp ứng đó:

Nhấn vào mẫu URI thứ hai /httpd/{httpdId} và nhập server1 làm giá trị của biến httpdId. Lưu ý rằng công cụ này không cho phép bạn nhấn vào Send cho đến khi bạn nhập vào một giá trị và hoàn tất mẫu URI. Nhấn vào Send và bạn sẽ nhìn thấy một đáp ứng chứa biểu diễn JSON của bản cài đặt httpd của bạn.

Kiểm thử cuối cùng của chúng ta với giao diện RESTdoc sẽ dành cho các đặc tính "khởi động" và "dừng lại" mà chúng ta đã sao chép từ hướng dẫn trước. Giao diện dựa trên -Zero của chúng ta đòi hỏi chúng ta gửi một POST HTTP hoặc DELETE HTTP tới /httpd/{httpdId}/process để khởi động hoặc dừng một máy chủ. Bạn cần phải thử nghiệm các đặc tính khởi động và dừng lại như sau:

1. Chọn tài nguyên tiến trình từ trang index của RESTdoc.
2. Nhấn vào mẫu URI POST HTTP và nhập server1 làm giá trị của biến httpdId. Nhấn vào Send.
3. Trong một cửa sổ trình duyệt (hoặc phiếu) khác, hãy truy cập vào http://localhost:8080. Bạn sẽ thấy thông báo chào mừng httpd mặc định: Nó hoạt động!
4. Từ trang RESTdoc, nhấn vào mẫu URI DELETE HTTP và nhập server1 làm giá trị của biến httpdId. Nhấn vào Send.
5. Làm mới trang http://localhost:8080. Bạn sẽ nhận được báo lỗi hết thời gian chờ kết nối, vì máy chủ không còn đang chạy nữa.
6. Từ trang RESTdoc, nhấn vào mẫu URI GET HTTP và nhập server1 làm giá trị của biến httpdId. Nhấn vào Send.
7. Bạn sẽ thấy một mã trạng thái 404, nó khẳng định rằng máy chủ đã dừng lại và các tạo phẩm của nó (tệp tin PID) đã bị xóa.

Trong phần này, tôi đã cho thấy làm thế nào để kiểm thử một API RESTful mà không viết bất kỳ mã hoặc tài liệu bổ sung thêm nào. Giao diện RESTdoc không cung cấp một phương tiện để tự động kiểm thử, nhưng nó rất quan trọng cho việc phát triển ứng dụng ban đầu hoặc cho các lập trình viên phía khách đang cố gắng tìm hiểu về một dịch vụ.

Kết luận

Trong bài viết này, bạn đã có thể thực hiện một giao diện RESTful dựa trên Zero cho httpd đầy đủ về chức năng ngang với phiên bản WS-* dựa trên Muse Apache của chúng ta. Việc kết hợp các kịch bản lệnh Groovy và các chú thích RESTdoc cung cấp cùng các đặc tính và hành vi giống như chúng ta đã có với các lớp Java và WSDL và chứng tỏ rằng REST có thể xử lý các nhiệm vụ vẫn được coi là "quá phức tạp" cho một mình HTTP. Các giải pháp REST và WS-*, mỗi cái có những điểm để tán thành và phản đối và bạn ưa thích cái nào hơn có thể thay đổi tùy theo dự án; Cuối cùng, chúng tôi cũng không chỉ cho bạn hướng tới cái này hay cái kia, chúng tôi đơn giản đã chỉ ra rằng cả hai đều là các lựa chọn dùng được.

Về đầu trang

Tải về

Thông tin về phương thức tải

Tài nguyên

Học tập

• Đọc bài chuẩn bị trước cho bài viết này, "Create a WSDM interface for an HTTP server using Apache Muse."
  
  
• Tìm hiểu về RESTdoc, công cụ làm tài liệu được sử dụng để xây dựng các bảng REST và các trang web thử nghiệm trong bài viết này.
  
  
• Tham gia cộng đồng Dự án Zero và xem người ta đang nói về những gì!
  
  
• Duyệt qua vùng phát triển Web của developerWorks để tìm các công cụ, mã và các tài nguyên để giúp bạn bắt đầu phát triển ứng dụng Web 2.0 ngày hôm nay.
  
  
• Ajax resource center của developerWorks được đóng gói với các thông tin dành cho tất cả các mức kỹ năng để giúp bạn xây dựng Ajax cho các ứng dụng của bạn và cải thiện đáng kể trải nghiệm web của người sử dụng của bạn.
  
  

Lấy sản phẩm và công nghệ

• Tải về Apache HTTP Server để bạn có thể chạy ứng dụng được xây dựng với hướng dẫn này.
  
  
• Tải về Project Zero và bắt đầu áp dụng các cách làm thực tiễn tốt nhất được trình bày trong bài viết này.
  
  

Thảo luận

• Tham gia vào diễn đàn thảo luận projectzero.org.
  
  

Đôi nét về tác giả

Chấm điểm bài này

Bình luận

Về đầu trang

Mục lục

• Trước khi bạn bắt đầu
• Giới thiệu
• Điểm lại: giao diện WSDM của chúng ta dành cho các máy chủ HTTP
• Ánh xạ WS-ResourceProperties tới REST
• Ánh xạ các hoạt động tùy chỉnh tới REST
• Thực hiện Quản lý Máy chủ HTTP bằng Zero
• Truy cập máy chủ HTTP Apache bằng Groovy
• Trưng ra các API REST bằng RESTdoc
• Kiểm thử các API REST bằng RESTdoc
• Kết luận
• Tải về
• Tài nguyên
• Đôi nét về tác giả
• Bình luận