• RESTful Web services


    API RESTful Service


    1. Giới thiệu về RESTful Service
    • 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.

    2. Nguyên tắc cơ bản để tạo ra RESTful Service
    a. Nguyên tắc 1: Sử dụng các phương thức HTTP một cách rõ rng
    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:
    • POST (HttpPost) – Tạo một tài nguyên trên máy chủ
    exe:
    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ụ sau:
    GET /users/MinhBu HTTP/1.1
    Host: myserver
    Accept: application/xml
    • GET (HttpGet) – Truy xuất một tài nguyên
    exe:
    GET /users/Trung 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ị.
    • PUT (HttpPut) – Thay đổi trạng thái một tài nguyên hoặc để cập nhật nó
    exe:
    PUT /users/MinhBu HTTP/1.1
    Host: myserver
    Content-Type: application/xml
    <?xml version="1.0"?>
    <user>
      <name>Hoang</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.
    • DELETE (HttpDelete) – Huỷ bỏ hoặc xoá một tài nguyên
    ====> Note: 
    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ư /adduserhoặ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.
    b. Nguyên tắc 2: Phi trạng thái
    Ta xem mô hình giữa trạng thái và phi trạng thái để dễ so sánh:
    Mô hình phi trạng thái:
    h68-2
    Mô hình trạng thái:
    h68-1
    So sánh 2 mô hình ta có thể thấy được các thành phần máy chủ phi trạng thái ít phức tạp hơn để thiết kế, viết và phân bổ thông qua máy chủ được cân bằng tải. Dịch vụ phi trạng thái không chỉ hoạt động tốt hơn, nó còn chuyển hầu hết vai trò duy trì trạng thái sang ứng dụng ở máy khách. 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ó
    c. Nguyên tắc 3: Hiển thị cấu trúc thư mục như URls
    Cấu trúc địa chỉ của RESTful service:
    • Giấu các đuôi tài liệu mở rộng của bản gốc trong máy chủ (.jsp, .php, .asp).
    • Để mọi thứ là chữ thường (thực ra là không phân biệt, nhưng cũng nên tuân thủ để khỏi phải nhớ HOA-thường lung tung).
    • Thay thế các khoảng trống bằng gạch chân hoặc gạch nối (một trong hai loại).
    • Tránh các chuỗi yêu cầu.
    • Thay vì sử dụng mã (404 Not Found) khi yêu cầu địa chỉ cho một phần đường dẫn thì luôn luôn cung cấp một trang mặc định hoặc tài nguyên như một phản hồi.
    d. Nguyên tắc 4: Chuyển đổi JavaScript Object Notation (JSON) và XML hoặc cả hai.
    • Là một bản tóm tắt các thuộc tính của những thứ trong mô hình dữ liệu hệ thống.
    • Định dạng dữ liệu mà ứng dụng và trao đổi dịch vụ trong mức đáp ứng yêu cầu/ phản hồi hoặc trong phần thân của HTTP.
    • Các chủ thể trong mô hình dữ liệu có liên quan với nhau.
    • Cấu trúc dịch vụ sao cho nó tận dụng được phần đầu chấp nhận HTTP có sẵn bên trong – một loại MIME
    3. Tổng quan
    • Ở bài viết này chúng ta đã hiểu thêm về RESTful, các nguyên tắc cơ bản để tạo ra RESTful service. Sử dựng các method GET, POST, PUT, DELETE để thiết lập ánh xạ  tới CSDL. Chuyển đôi Json và XML, nguyên tắc phi trạng thái
    4. Link Tham khảo
    a. Tìm hiểu 7 khái niệm về Web service
    b.  Creating and using an ASP.NET Web Service in Visual Web Developer
  • 0 nhận xét:

    Đăng nhận xét

    QUOTE & QUOTE

    Without requirements or design, programming is just the art of adding bugs to a blank text file.

    ADDRESS

    100000, My Dinh, Ha Noi, VN

    EMAIL

    minhbu883@mail.com
    minhnn17@fsoft.com.vn

    TELEPHONE

    +84964 214 883

    MOBILE

    +8438 5689 888