Restful API hay còn gọi là API RESTful là một kiểu kiến trúc cho giao diện chương trình ứng dụng ( API ) sử dụng các yêu cầu HTTP để truy cập và sử dụng dữ liệu. Dữ liệu đó có thể được sử dụng cho các kiểu dữ liệu GET, PUT, POST và DELETE, đề cập đến việc đọc, cập nhật, tạo và xóa các thao tác liên quan đến tài nguyên.
API cho một trang web là mã cho phép hai chương trình phần mềm giao tiếp với nhau. API giải thích cách thích hợp để nhà phát triển viết chương trình yêu cầu dịch vụ từ hệ điều hành hoặc ứng dụng khác.
RESTful API – còn được gọi là dịch vụ web RESTful hoặc API REST – dựa trên chuyển giao trạng thái đại diện ( REST ), là một kiểu kiến trúc và cách tiếp cận thông tin liên lạc thường được sử dụng trong phát triển dịch vụ web .
Công nghệ REST thường được ưa chuộng hơn các công nghệ tương tự khác. Điều này có xu hướng xảy ra vì REST sử dụng ít băng thông hơn , làm cho nó phù hợp hơn để sử dụng internet hiệu quả. Các API RESTful cũng có thể được xây dựng bằng các ngôn ngữ lập trình như JavaScript hoặc Python.
REST được sử dụng bởi các trình duyệt có thể được coi là ngôn ngữ của internet. Với việc sử dụng đám mây đang gia tăng , các API đang được người tiêu dùng đám mây sử dụng để hiển thị và tổ chức quyền truy cập vào các dịch vụ web. REST là một lựa chọn hợp lý để xây dựng các API cho phép người dùng kết nối, quản lý và tương tác với các dịch vụ đám mây một cách linh hoạt trong môi trường phân tán. Các API RESTful được sử dụng bởi các trang web như Amazon, Google, LinkedIn và Twitter.
Cách hoạt động của các API RESTful
API RESTful chia nhỏ một giao dịch để tạo ra một loạt các mô-đun nhỏ. Mỗi mô-đun giải quyết một phần cơ bản của giao dịch. Mô-đun này cung cấp cho các nhà phát triển rất nhiều tính linh hoạt, nhưng nó có thể là một thách thức đối với các nhà phát triển khi thiết kế API REST của họ từ đầu. Hiện tại, một số công ty cung cấp các mô hình cho các nhà phát triển sử dụng; các mô hình được cung cấp bởi Amazon S3 , Giao diện quản lý dữ liệu đám mây ( CDMI ) và OpenStack Swift là những mô hình phổ biến nhất.
API RESTful sử dụng các lệnh để lấy tài nguyên. Trạng thái của tài nguyên tại bất kỳ dấu thời gian nhất định nào được gọi là biểu diễn tài nguyên. API RESTful sử dụng các phương pháp luận HTTP hiện có được xác định bởi giao thức RFC 2616, chẳng hạn như:
GET để lấy một tài nguyên;
PUT để thay đổi trạng thái hoặc cập nhật tài nguyên, có thể là một đối tượng, tệp hoặc khối;
ĐĂNG để tạo tài nguyên đó; và
DELETE để loại bỏ nó.
Với REST, các thành phần được nối mạng là tài nguyên mà người dùng yêu cầu truy cập – giống như một hộp đen có chi tiết triển khai không rõ ràng. Tất cả các cuộc gọi là không trạng thái; không có gì có thể được giữ lại bởi dịch vụ RESTful giữa các lần thực thi.
Các định dạng dữ liệu mà REST API hỗ trợ bao gồm:
- ứng dụng / json
- ứng dụng / xml
- ứng dụng / x-wbe + xml
- application / x-www-form-urlencoded
- đa phần / biểu mẫu-dữ liệu
Sử dụng
Bởi vì các cuộc gọi là không trạng thái , REST rất hữu ích trong các ứng dụng đám mây. Các thành phần không trạng thái có thể được triển khai lại một cách tự do nếu có gì đó không thành công và chúng có thể thay đổi tỷ lệ để thích ứng với các thay đổi về tải . Điều này là do bất kỳ yêu cầu nào cũng có thể được chuyển hướng đến bất kỳ trường hợp nào của một thành phần; không thể có gì được lưu mà phải ghi nhớ trong lần giao dịch tiếp theo. Điều đó làm cho REST thích hợp hơn cho việc sử dụng web. Mô hình RESTful cũng hữu ích trong các dịch vụ đám mây vì ràng buộc với một dịch vụ thông qua API là vấn đề kiểm soát cách URL được giải mã. Điện toán đám mây và microservices là gần như chắc chắn để làm cho RESTful API thiết kế các quy tắc trong tương lai.
RESTful API thiết kế và các ràng buộc về kiến trúc
Thiết kế RESTful API được xác định bởi Tiến sĩ Roy Fielding trong luận án tiến sĩ năm 2000 của ông. Để trở thành một API RESTful thực sự, một dịch vụ web phải tuân thủ sáu ràng buộc kiến trúc REST sau:
- Sử dụng giao diện thống nhất (UI) . Tài nguyên phải được nhận dạng duy nhất thông qua một URL và chỉ bằng cách sử dụng các phương pháp cơ bản của giao thức mạng, chẳng hạn như DELETE, PUT và GET với HTTP, nếu có thể thao tác tài nguyên.
- Dựa trên máy khách-máy chủ . Cần có sự phân định rõ ràng giữa máy khách và máy chủ. Các mối quan tâm về giao diện người dùng và thu thập yêu cầu là miền của khách hàng. Truy cập dữ liệu, quản lý khối lượng công việc và bảo mật là miền của máy chủ. Sự kết hợp lỏng lẻo này của máy khách và máy chủ cho phép mỗi máy khách được phát triển và nâng cao độc lập với nhau.
- Hoạt động không trạng thái . Tất cả các hoạt động của máy khách-máy chủ phải ở trạng thái không trạng thái và mọi hoạt động quản lý trạng thái được yêu cầu sẽ diễn ra trên máy khách, không phải máy chủ.
- REST bộ nhớ đệm tài nguyên hữu ích . Tất cả các tài nguyên phải cho phép lưu vào bộ nhớ đệm trừ khi được chỉ định rõ ràng rằng không thể lưu vào bộ nhớ đệm.
- Hệ thống phân lớp . REST cho phép một kiến trúc bao gồm nhiều lớp máy chủ.
- Mã theo yêu cầu . Hầu hết thời gian, một máy chủ sẽ gửi lại các biểu diễn tĩnh của tài nguyên dưới dạng XML hoặc JSON . Tuy nhiên, khi cần thiết, các máy chủ có thể gửi mã thực thi đến máy khách.
Các thách thức API REST phổ biến
Bên cạnh những hạn chế về thiết kế và kiến trúc, các cá nhân sẽ phải đối mặt với một số thách thức với các API REST. Một số khái niệm có thể thách thức có thể bao gồm:
- Tính nhất quán của điểm cuối – đường dẫn của các điểm cuối phải nhất quán bằng cách tuân theo các tiêu chuẩn web chung, điều này có thể khó quản lý.
- Lập phiên bản API – URL điểm cuối không được vô hiệu khi được sử dụng trong nội bộ hoặc với các ứng dụng khác.
- Thời gian phản hồi lâu và quá nhiều dữ liệu – số lượng tài nguyên trả về có thể tăng kích thước theo thời gian, làm tăng thời gian tải và phản hồi.
- Đường dẫn điều hướng và vị trí nhập của người dùng – vì REST sử dụng đường dẫn URL cho các tham số đầu vào, nên việc xác định không gian URL có thể khó khăn.
- Bảo mật – có rất nhiều khía cạnh cần theo dõi, bao gồm cả việc sử dụng:
- HTTPS;
- chặn truy cập từ các địa chỉ IP và miền không xác định;
- xác thực URL;
- chặn trọng tải lớn đột xuất;
- yêu cầu ghi nhật ký; và
- điều tra các thất bại.
- Xác thực – sử dụng các phương pháp xác thực phổ biến như xác thực cơ bản HTTP (cho phép tên người dùng được mã hóa base64: chuỗi mật khẩu), khóa API, Mã thông báo web JSON và các mã thông báo truy cập khác. Ví dụ, OAuth 2.0 rất tốt cho việc kiểm soát truy cập .
- Yêu cầu và dữ liệu – yêu cầu có thể có nhiều dữ liệu và siêu dữ liệu hơn mức cần thiết hoặc có thể cần nhiều yêu cầu hơn để có được tất cả dữ liệu. API có thể được điều chỉnh cho điều này.
- Kiểm tra API – có thể là một quá trình dài để thiết lập và chạy. Mỗi phần của quá trình có thể dài hoặc đầy thử thách. Việc kiểm tra cũng có thể được thực hiện trong dòng lệnh với tiện ích Curl. Các phần của quá trình thử nghiệm có thể thách thức bao gồm:
- Xác định mã lỗi và thông báo.
- Với mã lỗi, thông thường hơn là sử dụng mã lỗi HTTP tiêu chuẩn. Những điều này được khách hàng và nhà phát triển công nhận thường xuyên hơn.
- Việc xử lý lỗi có thể không có cách nào để phân biệt xem phản hồi có thành công hay không ngoài việc phân tích cú pháp nội dung hoặc kiểm tra lỗi.
REST so với SOAP
REST và Giao thức truy cập đối tượng đơn giản (SOAP) cung cấp các phương pháp khác nhau để gọi một dịch vụ web. REST là một kiểu kiến trúc, trong khi SOAP định nghĩa một đặc tả giao thức truyền thông tiêu chuẩn để trao đổi thông điệp dựa trên XML. Các ứng dụng REST có thể sử dụng SOAP.
Các dịch vụ web RESTful là không trạng thái. Việc triển khai dựa trên REST rất đơn giản so với SOAP, nhưng người dùng phải hiểu ngữ cảnh và nội dung đang được truyền đi, vì không có bộ quy tắc tiêu chuẩn nào để mô tả giao diện dịch vụ web REST. Dịch vụ REST rất hữu ích cho các thiết bị cấu hình hạn chế, chẳng hạn như thiết bị di động và dễ dàng tích hợp với các trang web hiện có.
SOAP yêu cầu ít mã đường ống dẫn nước hơn – nghĩa là mã cơ sở hạ tầng, cấp thấp kết nối các mô-đun mã chính với nhau – so với thiết kế dịch vụ REST. Ngôn ngữ Mô tả Dịch vụ Web mô tả một tập hợp các quy tắc chung để xác định các thông báo, ràng buộc, hoạt động và vị trí của dịch vụ. Dịch vụ web SOAP rất hữu ích cho quá trình xử lý không đồng bộ và lệnh gọi.
Lịch sử của các API RESTful
Trước REST, các nhà phát triển đã sử dụng SOAP để tích hợp các API. Để thực hiện một cuộc gọi, các nhà phát triển đã viết tay một tài liệu XML với một Cuộc gọi Thủ tục Từ xa ( RPC ) trong nội dung. Sau đó, họ chỉ định điểm cuối và ĐĂNG phong bì SOAP của họ đến điểm cuối.
Năm 2000, Roy Fielding và một nhóm các nhà phát triển quyết định tạo ra một tiêu chuẩn để bất kỳ máy chủ nào cũng có thể nói chuyện với bất kỳ máy chủ nào khác. Ông đã định nghĩa REST và các ràng buộc về kiến trúc được giải thích ở trên trong năm 2000 Ph.D. luận văn tại Đại học California, Irvine. Những quy tắc chung này giúp các nhà phát triển tích hợp phần mềm dễ dàng hơn.
Salesforce là công ty đầu tiên bán API như một phần của gói “Internet as a Service” vào năm 2000. Tuy nhiên, một số nhà phát triển thực sự có thể sử dụng API XML phức tạp. Sau đó, eBay đã xây dựng API REST, mở rộng thị trường cho bất kỳ trang web nào có thể truy cập API của nó. Điều này đã thu hút sự chú ý của một gã khổng lồ thương mại điện tử khác và Amazon đã công bố API của mình vào năm 2002.
Flickr ra mắt API RESTful của riêng mình vào tháng 8 năm 2004, cho phép các blogger dễ dàng nhúng hình ảnh vào các trang web và nguồn cấp dữ liệu mạng xã hội của họ. Facebook và Twitter đều phát hành API của họ vào năm 2006, chịu áp lực của các nhà phát triển, những người đã loại bỏ các trang web và tạo ra các API “Frankenstein”. Khi Amazon Web Services ( AWS ) giúp khởi chạy đám mây vào năm 2006, các nhà phát triển có thể truy cập không gian dữ liệu trong vài phút bằng API REST của AWS và yêu cầu về các API công khai nhanh chóng tăng lên.
Kể từ đó, các nhà phát triển đã chấp nhận các API RESTful, sử dụng chúng để thêm chức năng cho các trang web và ứng dụng của họ. Ngày nay, các API REST được coi là “xương sống của internet.”
