Thứ Sáu, 14 tháng 10, 2016

WEBENT - Buổi 8: RESTful Web Service

I. Web Service:
1. Khái niệm: Phần mềm có thể xác định bằng URL, thực hiện chức năng đưa ra các thông tin mà người dùng yêu cầu. Đồng thời Web Service còn cho phép Client và Server tương tác với nhau trong nhiều môi trường khác nhau.
2. Ưu điểm:
 - Nâng cao khả năng tái sử dụng.
 - Tạo mối quan hệ tương tác lẫn nhau , dễ dàng cho việc phát triển các ứng dụng phân tán.
Cung cấp khả năng hoạt động với ứng dụng hay phần mềm khác nhau chạy trên nhiều nền tảng khác nhau.
 - Sử dụng các giao thức và chuẩn mở. Giao thức và định dạng dữ liệu dựa trên văn bản (text), giúp các lập trình viên dễ dàng hiểu được.
 - Phát triển hệ thống tích hợp và tương tác hiệu quả với các doanh nghiệp.

3. Nhược điểm:
 - Có nhiều chuẩn khiến người dùng khó nắm bắt.
 - Nếu Web Service mà chết trong một khoảng thời gian thì sẽ khiến giao diện không đổi, thiếu các giao thức cho việc vận hành, và có thể lỗi nếu máy khách không được nâng cấp.
 - Vấn đề bảo mật và an toàn phải được quan tâm nhiều hơn.


II. RESTful Web Service
1. Khái niệm:
 - REST (Representational State Transfer) đã được chọn sử dụng rộng rãi thay cho Web service dựa trên SOAP và WSDL. Bằng chứng quan trọng của sự thay đổi này chính là việc các công ty dẫn đầu trong lĩnh vực cung cấp dịch vụ mạng 2.0 như Yahoo, Google và Facebook đã phản đối các giao thức dựa trên SOAP hoặc WSDL và ủng hộ phương thức hướng đến tài nguyên và dễ sử dụng đối với các dịch vụ của họ. Trong bài viết này, Alex Rodriguez sẽ giới thiệu với các bạn các nguyên lý cơ bản của REST.
 - 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.


2. Sử dụng phương thức HTTP một cách rõ ràng:
 - Để 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.


3. Dịch vụ trạng thái và phi trạng thái:
 - Một ứng dụng có thể yêu cầu trang sau trong một tập hợp các trang kết quả, giả sử rằng dịch vụ theo sát ứng dụng dừng lại ở nơi trong khi điều chỉnh tập hợp đó. Đối với thiết kế trạng thái, dịch vụ gia tăng và lưu giữ một previousPage (trang trước) thay đổi ở nơi để có thể phản hồi các lệnh tiếp theo.
 - Dịch vụ trạng thái như thế này trở nên phức tạp. Trong môi trường Nền tảng Java, Phiên bản Doanh nghiệp (EE), dịch vụ trạng thái yêu cầu rất cẩn thận lúc ban đầu để lưu trữ hiệu quả và cho phép đồng bộ hoá dữ liệu Session (phiên làm việc) qua một hệ thống Container Java EE. Trong môi trường này, có một vấn đề quen thuộc đối với các chuyên viên phát triển Servlet/JavaServer Pages (JSP) và Enterprise JavaBeans (EJB), những người này thường gặp khó khăn khi tìm gốc rễ nguyên nhân của java.io.NotSerializableException trong khi tái tạo Session.
 - Liệu nó được chuyển bởi thành phần chứa Servlet trong khi HttpSession được tái tạo hoặc chuyển đi bởi thành phần chứa EJB trong khi sao bản EJB trạng thái, đó là vấn đề mà có thể làm các chuyên viên phát triển mất nhiều ngày để xác định mấu chốt một đối tượng mà không thực thi Serializable, đôi khi trong một đồ thị phức tạp của các đối tượng mà đóng góp nên trạng thái của máy chủ. Ngoài ra, phần tối ưu hoá làm đội thêm chi phí ảnh hưởng đến hiệu quả của máy chủ. 
 - Mặt khá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ó. 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.
 - 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ủ: 
  • Tạo ra các phản hồi bao gồm các đường dẫn tới nguồn tài nguyên 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 RESTful Web service đ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.
  • Tạo 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ữ).
 + 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ã phản hồi HTTP 304 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ộ, lưu giữ một bản sao mới nhất của tài nguyên đại diện, 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 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 Web service 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ủ.

4. Đưa ra cấu trúc thư mục giống URIs:
 - Từ điểm hiện có của tài nguyên địa chỉ ứng dụng máy khách, các đường dẫn xác định tính hiện thực của Web service REST như thế nào, và được sử dụng theo cách các chuyên viên thiết kế có thể tham gia. Tính năng thứ ba của Web service RESful về tất cả đường dẫn.
 - Các địa chỉ Web service REST nên có tính hiện thực theo nghĩa rằng chúng dễ dàng đối với người dùng. Có thể nghĩ rằng một địa chỉ đường dẫn như là giao diện tự đóng gói mà đòi hỏi ít lý giải hoặc tham chiếu, nếu có, đối với một nhà phát triển để hiểu nó nhắm đến điểm gì và phân phát tài nguyên liên quan. Cuối cùng, cấu trúc của một địa chỉ nên rõ ràng, có thể đoán được và dễ hiểu.
 - Một cách để đạt được mức độ sử dụng này là xác định cấu trúc thư mục giống URIs. Loại URI này có thứ bậc, có điểm khởi nguồn tại một đường dẫn đơn giản, và có nhánh đi ra là các nhánh phụ thể hiện các vùng chính của dịch vụ. Theo định nghĩa này, một URI không chỉ là một chuỗi bị cắt không giới hạn, mà còn là một cây với các nhánh chính và nhánh dọc nối với nhau tại các nút. Ví dụ, trong một thảo luận dịch vụ nhỏ thu thập các chủ đề từ Java tới bài viết, bạn có thể định nghĩa một tập hợp được cấu trúc bởi URIs giống như sau:
1
http://www.myservice.org/discussion/topics/{topic}
 - Phần gốc, /discussion, có một nút /topics bên dưới nó. Phía dưới là một chuỗi tên các chủ đề, như chuyện xã hội, kỹ thuật, ... Mỗi chủ đề chỉ ra một mạch thảo luận. Trong cấu trúc này, dễ dàng kéo các mạch thảo luận bằng cách gõ một vài thứ sau /topics/.
 - Trong một vài trường hợp, đường dẫn tới một tài nguyên cho mượn chính nó đặc biệt tốt với cấu trúc giống cây thư mục. Ví dụ, tài nguyên được cấu trúc bởi ngày, điều mà phối hợp rất tốt để sử dụng một cú pháp phân cấp.

 - Phần đầu tiên trong đường dẫn là năm có bốn chữ số, phần thứ hai là ngày có hai chữ số, và phần thứ ba là tháng có hai chữ số. Có vẻ hơi ngu ngốc khi giải thích theo cách này, nhưng đây là mức độ đơn giản. Con người và máy móc có thể dễ dàng sinh ra các cấu trúc URIs giống như vậy vì chúng dựa trên các nguyên tắc. Bổ sung vào các phần đường dẫn trong các khe của một cú pháp làm cho chúng tốt hơn vì có một mẫu xác định từ đó để soạn chúng.
1
http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}
 - Một vài hướng dẫn bổ sung để lưu ý trong khi nói về cấu trúc địa chỉ của Web service RESTful là:
 + 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), nếu có, vì vậy bạn có thể giấu một số thứ mà không cần thay đổi địa chỉ Urls.
 + Để mọi thứ là chữ thường.
 + Thay thế các khoảng trống bằng gạch chân hoặc hoặc gạch nối (một trong hai loại).
 + Tránh các chuỗi yêu cầu càng nhiều càng tốt.
 + Thay vì sử dụng mã (404 Not Found) khi yêu cầu địa chỉ cho một phần đường dẫn, 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.
 - Các địa chỉ URIs nên giữ nguyên để khi tài nguyên thay đổi hoặc khi tiến hành thay đổi dịch vụ, đường liên kết cũng sẽ giữ nguyên. Việc này cho phép đánh dấu lại vị trí đang đọc. Nó cũng rất quan trọng vì mối liên quan giữa các tài nguyên mà được mã hoá trong các địa chỉ được giữ nguyên độc lập với các mối liên quan đại diện khi chúng được lưu trữ.



5. Chuyển đổi XML, JSON, hoặc cả hai:
 - Một tài nguyên đại diện điển hình phản ánh trạng thái hiện tại của một tài nguyên, và các thuộc tính của nó, tại thời điểm một ứng dụng máy khách yêu cầu nó. Các đại diện tài nguyên theo nghĩa này là chỉ các bản tóm tắt lúc đó. Điều này có thể đơn giản như một đại diện của một bản ghi trong một cơ sở dữ liệu, bao gồm một tổng thể giữa tên các cột và các thẻ XML, nơi các giá trị thành phần trong XML bao gồm các giá trị dòng. Hoặc nếu hệ thống có một mô hình dữ liệu, thì theo định nghĩa này một tài nguyên đại diện 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. Đây là những điều bạn muốn Web services REST mang đến.
 - Những trở ngại cuối cùng, đi kèm với thiết kế Web service RESTful, phải làm với đị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. Đây chính là điều nó làm để giữ mọi thứ đơn giản, có thể đọc được và kết nối được.
 - Các chủ thể trong mô hình dữ liệu của bạn thường liên quan đến nhau theo cách nào đó, và mối liên hệ giữa mô hình dữ liệu chủ thể (tài nguyên) nên được phản ánh theo cách chúng được đại diện để chuyển đến một ứng dụng máy khách. Trong dịch vụ chuỗi thảo luận, một ví dụ của đại diện tài nguyên được kết nối có thể bao gồm một chủ đề thảo luận gốc và các thuộc tính của nó, và các đường dẫn được nhúng vào các phản hồi nhất định của chủ đề đó. 
 - Cuối cùng, để đưa đến khả năng yêu cầu loại nội dung cụ thể cho các ứng dụng máy khách mà phù hợp nhất với chúng, hãy cấu trúc dịch vụ của bạn sao cho nó tận dụng được phần đầu chấp nhận HTTP sẵn có bên trong, nơi giá trị của phần đầu là một loại MIME. Một vài loại MIME thông thường được sử dụng bởi dịch vụ RESTful được thể hiện trong Bảng 1.
 - Nó cho phép dịch vụ được nhiều khách hàng khác nhau sử dụng, viết bằng các ngôn ngữ khác nhau, chạy trên nền và thiết bị khác nhau. Sử dụng kiểu MIME và phần đầu HTTP Accept là một cơ chế được biết như là nội dung thương thuyết, cái mà cho phép máy khách chọn định dạng dữ liệu nào là đúng với chúng và tối thiểu hoá sự nối lại giữa dịch vụ và các ứng dụng mà sử dụng nó.

6. Tổng kết: 
 - REST không phải là sự lựa chọn luôn đúng. Đã có trường hợp khi thiết kế Web service, nó có sự kém độc lập đối với phần mềm trung gian (Ví dụ: Một ứng dụng máy chủ) so với loại dựa trên SOAP hặc WSDL. Có nghĩa REST là một sự quay lại con đường mạng trước thời đại ứng dụng máy chủ rất lớn, kể cả ấn tượng các chuẩn của internet thời kỳ đầu, địa chỉ và HTTP. Bạn vừa nghiên cứu nguyên tắc gọi là thiết kế giao diện RESTful, XML so với HTTP là một giao diện vượt trội cho phép các ứng dụng bên trong, như các giao diện người dùng dựa trên Asynchronous JavaScript + XML (Ajax), dễ dàng kết nối, xác định, và tiêu thụ tài nguyên. Thực tế, sự tương thích lớn giữa Aax và REST đã nhận được rất nhiều sự chú ý gần đây.
 - Đưa một tài nguyên hệ thống thông qua một RESTful API là một cách linh động để cung cấp các loại ứng dụng khác nhau với dữ liệu đã được định dạng theo cách tiêu chuẩn. Nó giúp đáp ứng các yêu cầu tích hợp, điều rất quan trọng để xây dựng hệ thống khi dữ liệu được kết hợp dễ dàng (mashups) và để mở rộng hoặc xây dựng trên một gói hệ thống căn bản. Dịch vụ RESTful có thể rất lớn đối với một số thứ. Bài viết này hướng dẫn dựa vào nguyên lý cơ bản trên và hy vọng bằng cách nào đó sẽ khuyến khích bạn khám phá chủ đề này.

III. Sự khác nhau giữa SOAP và RESTful:

STTSOAPREST
1)SOAP là một giao thức.REST là một cách thiết kế kiến trúc.
2)SOAP là từ viết tắt của Simple Object Access Protocol (Giao thức truy cập đối tượng đơn giản).REST viết tắt của REpresentational State Transfer.
3)SOAP không thể sử dụng REST bởi vì nó là một giao thức.REST có thể dùng các web services sử dụng SOAP vì nó có thể dùng bất kỳ giao thức nào như HTTP, SOAP.
4)SOAP cung cấp các giao diện dịch vụ(services interfaces) cho các thành phần bên ngoài sử dụng.REST sủ dụng đỉa chỉ URI để cung cấp các dịch vụ.
5)JAX-WS là java API cài đặt web services theo giao thức SOAP.JAX-RS là java API cài đặt web services theo kiến trúc RESTful.
6)SOAP định nghĩa các chuẩn và quy tắc chặt chẽ.REST không định nghĩa nhiều chuẩn như SOAP.
7)SOAP sử dụng băng thông và tài nguyên nhiều hơn REST.REST sử dụng băng thông và tài nguyên ít hơn SOAP.
8)SOAP định nghĩa chuẩn bảo mật của riêng nó.RESTful kế thừa chuẩn bảo mật tầng vận tải của giao thức mạng.
9)SOAP chỉ hỗ trợ định dạng dữ liệu XML.REST hỗ trợ các định dạng dữ liệu khác nhau như text, HTML, XML, JSON.
10)SOAP ít được dùng hơn REST.REST được ưa chuộng hơn SOAP.
11)Được thiết kế để dùng trong tính toán phân tán.Thương không được dùng trong môi trường tính toán phân tán.
12)Tin cậy hơn.Ít tin cậy hơn – chẳng hạn, HTTP DELETE có thể trả về trạng thái OK ngay cả khi tài nguyên không được xóa.
13)Hỗ trợ hầu hết các chuẩn bảo mật, tin cậy và giao dịch.Sử dụng tốt với các giao thức như: HTTP, SSL. Các phương thức DELETE và PUT thường bị vô hiệu hóa bởi tường lửa hoặc vấn đề bảo mật.
14)SOAP hỗ trợ cả hai giao thức SMTP và HTTP.REST gắn với giao thức HTTP.

Không có nhận xét nào:

Đăng nhận xét