Trao đổi dữ liệu trên nhiều nền tảng trở nên quan trọng hơn bao giờ hết trong kỷ nguyên tích hợp. Hãy xem xét một cửa hàng trực tuyến không có tích hợp. Trang web của bạn sẽ phải phát triển các hệ thống để quản lý tài khoản người dùng, đăng ký email, xử lý thanh toán , giao hàng và các tác vụ khác ngoài việc quản lý danh sách sản phẩm. Sẽ hiệu quả hơn nếu thuê ngoài các nhiệm vụ này cho các nhà cung cấp khác vì đây không phải là một tùy chọn có thể mở rộng.
Giao diện lập trình ứng dụng hoặc API web là thứ mà các chương trình phần mềm sử dụng để giao tiếp với nhau. API cung cấp một giao thức nhất quán để trao đổi dữ liệu giữa hai chương trình. Với sự trợ giúp của API web, cửa hàng trực tuyến của bạn có thể giao tiếp với phần mềm giao hàng, ứng dụng khách, ứng dụng thanh toán và bất kỳ kết nối cần thiết nào khác.
Có nhiều cách khác nhau để tạo API; tuy nhiên, nếu bạn muốn thêm các kết nối phần mềm vào các dịch vụ của mình, thì có một kỹ thuật độc đáo mà bạn nên làm quen: các dịch vụ web API REST. Trong bài viết này, chúng ta sẽ thảo luận về các ví dụ về API REST, API REST là gì, cách API REST hoạt động, API REST được sử dụng để làm gì, lịch sử, các thành phần của nó, v.v.
API REST chính xác là gì?
Chuyển trạng thái đại diện hoặc các dịch vụ web API REST là phương pháp tiêu chuẩn nhất để liên kết các thành phần trong khung vi dịch vụ vì chúng cung cấp một cách linh hoạt, di động để kết hợp các ứng dụng. REST là một thiết kế API phổ biến mà chúng tôi sử dụng để tương tác với các bên liên quan bên trong và bên ngoài theo cách được chuẩn hóa và có thể dự đoán được.
Người dùng ứng dụng web thường xuyên sử dụng các dịch vụ web API REST để giao tiếp với nhau. Ví dụ: thu thập và xem xét chi tiết tài khoản trong một chương trình truyền thông xã hội . Các trình duyệt API REST có thể được xem như cú pháp của web. Khách hàng trực tuyến sử dụng API web để cung cấp và quản lý quyền truy cập vào các hoạt động kỹ thuật số khi mức sử dụng đám mây tăng lên.
Việc thiết kế các API web cho phép khách hàng kết nối, quản trị và tương tác với các dịch vụ web kỹ thuật số một cách linh hoạt trong bối cảnh phân tán là một quyết định hợp lý. Các trang web như Google, eBay, Facebook, Amazon và Twitter sử dụng các dịch vụ web RESTful. Các ứng dụng khách hiện có thể sử dụng REST để truy cập các dịch vụ web này.
Công nghệ REST được ưa chuộng hơn các công nghệ liên quan khác. Điều này là do các dịch vụ web REST tiêu thụ ít băng thông hơn, khiến chúng trở nên lý tưởng cho hoạt động trực tuyến hiệu quả. Các dịch vụ web RESTful cũng có thể được phát triển bằng các ngôn ngữ lập trình như JavaScript hoặc Python.
API REST hoạt động như thế nào?
Để biết API REST hoạt động như thế nào, chúng ta phải xác định một số thuật ngữ chính:
Khách hàng
Người dùng API được gọi là khách hàng. Máy khách gửi truy vấn tới các API web để lấy dữ liệu hoặc áp dụng các sửa đổi cho chương trình. Trình duyệt internet của bạn là một ứng dụng khách; nó giao tiếp với các API web khác nhau để lấy nội dung trang. Máy tính của bạn nhận được thông tin cần thiết, sau đó được hiển thị trên màn hình.
Sau đây là các phương thức HTTP phổ biến nhất:
- Sử dụng yêu cầu GET để trả về dữ liệu được yêu cầu hoặc tài nguyên được yêu cầu.
- Sử dụng yêu cầu POST để tạo tài nguyên mới
- Sử dụng lệnh PUT để thay đổi hoặc tiếp tục cập nhật tài nguyên hiện có
- Sử dụng lệnh DELETE để loại bỏ tài nguyên.
Ví dụ: yêu cầu HTTP tới API của Youtube có thể là tài nguyên yêu cầu GET cho một video hoặc bài đăng cụ thể hoặc yêu cầu POST để xuất bản ảnh mới. Bạn có thể sử dụng phương thức yêu cầu POST để xuất bản bài viết mới. Tương ứng, một nền tảng dịch vụ web dành cho khách hàng tích hợp với triển khai hệ thống trả lời tự động có thể sử dụng lệnh PUT để cập nhật hoặc loại bỏ lời chào tùy chỉnh.
Nhận yêu cầu
- Có thể lưu vào bộ nhớ đệm yêu cầu GET. Lịch sử của trình duyệt bao gồm các yêu cầu GET.
- Có thể đánh dấu các yêu cầu NHẬN.
- Không bao giờ sử dụng các yêu cầu GET trong khi làm việc với tài liệu quan trọng.
- Có các giới hạn về độ dài đối với các yêu cầu GET.
- Chỉ truy vấn dữ liệu được thực hiện thông qua yêu cầu GET
Phương thức ĐĂNG
Yêu cầu POST là một phương thức đăng để gửi thông tin đến máy chủ để thêm hoặc cập nhật tài nguyên. Nội dung yêu cầu của yêu cầu HTTP chứa dữ liệu được xuất bản lên phía máy chủ:
- POST yêu cầu phương thức đăng không bao giờ đi vào bộ đệm.
- Yêu cầu POST không được lưu trữ trong lịch sử của trình duyệt.
- Yêu cầu POST không thể đánh dấu
Nội dung phản hồi
Phần thân phản hồi là một trong những yếu tố quan trọng của API RESTful. Dữ liệu được yêu cầu được bao gồm trong nội dung phản hồi. Nội dung phản hồi có thể bao gồm dữ liệu liên quan đến đầu ra và cổng logic đầu ra.
Nguồn
Mọi dữ liệu mà API web có thể cung cấp cho người dùng đều là tài nguyên. Ví dụ: một cá nhân, trang, ảnh hoặc nhận xét đều có thể được coi là tài nguyên trong Facebook API. Mã định danh tài nguyên là một thuật ngữ đặc biệt được cấp cho mỗi tài nguyên.
Máy chủ web
Chương trình chấp nhận phần thân yêu cầu của khách hàng sử dụng máy chủ web, nơi chứa các tài nguyên mà người tiêu dùng yêu cầu. Máy chủ có thể giao tiếp với khách hàng thông qua API mà không cần cung cấp cho khách hàng quyền truy cập ngay vào thông tin được lưu trong cơ sở dữ liệu của nó. Khi người dùng truy cập các dịch vụ web RESTful để gửi nội dung yêu cầu, máy chủ sẽ gửi mô tả chuẩn hóa về trạng thái của tài nguyên tới trình duyệt.
Điều này có nghĩa là máy chủ bằng cách nào đó không gửi tài nguyên chính xác cho máy khách mà phản ánh tình trạng của nó, tức là tình hình của tài nguyên tại một dấu thời gian cụ thể. Để hỗ trợ tính dễ hiểu, các câu trả lời được trả về ở định dạng nhẹ.
JSON (Ký hiệu đối tượng JavaScript) được sử dụng rộng rãi vì cả người và máy đều có thể đọc được và vượt trội trong việc giúp thúc đẩy khả năng truy cập web. JSON chủ yếu được sử dụng để gửi nội dung yêu cầu trong các ứng dụng web và ứng dụng khách. Nó là một hình thức tương thích với nhiều loại mã hóa. Các định dạng dữ liệu API không phải JSON liên quan đến XML , YAML, CSV, HTML và văn bản thuần túy. Người dùng API có thể chọn bất kỳ định dạng dữ liệu nào họ muốn bằng cách sử dụng các loại phương tiện tùy chỉnh.
Lịch sử của API REST
Nhiều lập trình viên đã phải làm việc với SOAP trước REST để kết hợp các API. Xây dựng, sử dụng và sửa lỗi SOAP là những nhiệm vụ khó khăn nổi tiếng. Rất may, REST được phát triển bởi một nhóm lập trình viên dưới sự chỉ đạo của Roy Fielding, thay đổi mãi mãi môi trường API.
Đây là trình tự thời gian phát triển API REST theo thời gian:
Trước khi nghỉ ngơi
Các lập trình viên đã viết thủ công một tệp XML chứa Lệnh gọi thủ tục từ xa (RPC) bên trong nội dung để kết nối các API web bằng SOAP. Sau đó, các nhà thiết kế sẽ POST gói SOAP của họ tới điểm cuối đã chỉ định.
Vào năm 2000
Một nhóm lập trình viên do Roy Fielding đứng đầu đã chọn phát triển một khung cho phép bất kỳ máy chủ nào giao tiếp với bất kỳ máy chủ nào khác. Anh ấy đã đặt ra các hạn chế cho API REST. Bởi vì những hướng dẫn này là phổ biến, việc phát triển phần mềm sẽ dễ dàng hơn.
Trong năm 2002
eBay đã phát triển API RESTful của mình vào năm 2002, mở thị trường của mình cho bất kỳ trang web nào có thể hưởng lợi từ nó. Vì điều này, một người khổng lồ khác của thương mại điện tử, Amazon, bắt đầu quan tâm đến nó và vào năm 2002, đã phát hành API RESTful của nó.
Trong năm 2004–2006
Dịch vụ web RESTful của Flickr được phát hành vào năm 2004, cho phép người viết nhanh chóng thêm ảnh vào trang web và các bài đăng trên mạng xã hội của họ. Khi Twitter và Facebook nhận thấy một số lượng đáng kể các lập trình viên đang quét các trang web và tạo API "Frankenstein", cả hai đều đã tiết lộ API của mình khoảng hai năm sau đó.
Năm 2006-nay
Các dịch vụ web RESTful hiện được chấp nhận rộng rãi bởi các lập trình viên, những người sử dụng các dịch vụ web RESTful này để cải thiện hiệu suất của các ứng dụng và trang web của họ. AppMaster tạo điều kiện hợp tác và giúp xây dựng API dễ dàng hơn, cho phép bạn thực hiện việc đó nhanh hơn.
API REST được sử dụng để làm gì?
Một trong những lợi ích chính của dịch vụ web RESTful là nó cung cấp rất nhiều tính linh hoạt, cho phép bạn sử dụng API RESTful này hiệu quả hơn. Dưới đây là một số ví dụ về API REST về mục đích sử dụng của API REST.
Ứng dụng dựa trên đám mây
Do tính không trạng thái của các lệnh gọi, API REST có lợi thế trong các ứng dụng đám mây. Các mô-đun không trạng thái có thể dễ dàng cài đặt lại và phát triển để đáp ứng yêu cầu về dung lượng nếu xảy ra sự cố. Một chương trình phần mềm kết hợp các thành phần cục bộ và dựa trên internet là một ứng dụng đám mây. Mô hình này sử dụng các máy chủ ở xa được truy cập bởi trình duyệt web và các dịch vụ web trên internet đang diễn ra để thực hiện các hướng dẫn.
Vị trí truyền thống của các máy chủ ứng dụng đám mây là một hệ thống máy tính ở xa do nhà điều hành mạng điện toán đám mây bên thứ ba điều hành. Thư, chia sẻ và lưu trữ tài liệu, nhập đơn đặt hàng, kiểm soát hàng tồn kho, Microsoft Word, quản lý quan hệ khách hàng ( CRM ), thu thập thông tin cũng như tài chính và kế toán là những ví dụ về công việc được thực hiện với các ứng dụng dựa trên đám mây.
Các giao diện lập trình ứng dụng REST ( API ) có thể được sử dụng để kết nối các nguồn thông tin và tài nguyên lưu trữ bên ngoài. Các lập trình viên có thể làm cho các ứng dụng đám mây nhỏ hơn bằng cách sử dụng API REST để truyền dữ liệu sang các chương trình khác để xử lý hoặc phân tích các phép tính và trả kết quả cho chương trình phần mềm. Các API đã thử nghiệm thực thi tính đồng nhất hoạt động, có thể đẩy nhanh quá trình sản xuất và tạo ra kết quả thực tế.
Ví dụ điển hình về ứng dụng đám mây là Google Docs hoặc Office 365. Tất cả những gì bạn cần cho Google Docs hoặc Office 365 là một máy tính có thể chạy các công cụ tìm kiếm và dịch vụ web trên internet. Mạng máy tính cung cấp giao diện người dùng và hoạt động, bao gồm lưu trữ thông tin. Công ty của bạn có thể lưu trữ nhiều ứng dụng đám mây riêng biệt bằng máy chủ ứng dụng đám mây.
Dịch vụ điện toán đám mây
Vì bạn cần quản lý cách URL được xử lý để kết nối với tài nguyên thông qua API, API REST cũng hữu ích cho các dịch vụ web trên đám mây. Kiến trúc dịch vụ web RESTful có thể sẽ trở thành tiêu chuẩn trong tương lai do các ứng dụng đám mây. Các lập trình viên sử dụng các dịch vụ web RESTful để kết nối với các dịch vụ đám mây bằng internet. Nhà phát triển tạo mã sử dụng API của nhà cung cấp internet, cung cấp thông tin đầu vào và biến cần thiết, sau đó kiểm tra câu trả lời để đảm bảo hành động hoạt động như mong đợi.
Người dùng cuối có thể truy cập các ứng dụng khách hoặc dịch vụ web do dịch vụ web đám mây cung cấp, chẳng hạn như cơ sở hạ tầng tính toán, hệ thống lưu trữ hoặc hệ thống theo dõi, sử dụng dịch vụ đám mây như dịch vụ web RESTful. API phác thảo các khả năng và hoạt động của ứng dụng và các chi tiết cụ thể cần thiết để thực hiện chúng. Để duy trì quyền riêng tư và bảo mật của máy khách, API thường phụ thuộc vào cơ chế cấp phép và khả năng tương tác của REST hoặc Giao thức truy cập đối tượng đơn giản (SOAP) như OAuth 2.0.
Nhiều dịch vụ web được gọi là "dịch vụ đám mây" và được cung cấp cho các doanh nghiệp và người tiêu dùng trực tuyến theo yêu cầu. Các dịch vụ web này được tạo ra để cung cấp khả năng truy cập nhanh chóng, không tốn kém vào các công cụ và ứng dụng mà không yêu cầu về phần cứng hoặc cơ sở hạ tầng. Hầu hết nhân viên sử dụng dịch vụ web đám mây cho mọi thứ, từ email đến cộng tác tài liệu.
sử dụng web
Có thể lấy các API web này từ dự án web của người dùng, ứng dụng iPhone , thiết bị IoT hoặc Windows Mobile vì REST không phụ thuộc vào chức năng phía máy khách. Bạn có thể tạo kiến trúc cho doanh nghiệp của mình mà không bị giới hạn trong một khuôn khổ phía máy khách cụ thể.
Một ví dụ API REST
Hãy thảo luận về một ví dụ API REST. Nhấp vào liên kết bên dưới để yêu cầu Cơ sở dữ liệu Trivia Mở một cuộc điều tra tình báo tùy ý: Các dịch vụ web RESTful như vậy đã được sử dụng để cung cấp API web công khai. Máy tính của bạn sẽ hiển thị một câu hỏi trắc nghiệm đơn lẻ và câu trả lời ở định dạng JSON.
Sử dụng bất kỳ trình duyệt HTTP nào, chẳng hạn như url, bạn có thể đưa ra truy vấn sau và nhận được phản hồi trong nội dung phản hồi: https://opentdb.com/api.php?amount=1&category=18
Nội dung phản hồi của tệp XML của dịch vụ web sẽ chứa tất cả thông tin của nhân viên.
Tất cả các phương ngữ lập trình và công cụ dành cho nhà phát triển được sử dụng rộng rãi đều có thư viện ứng dụng khách HTTP, chẳng hạn như truy xuất trong JavaScript, Node.js và Deno và tệp nhận nội dung() trong PHP. Một câu trả lời JSON có thể được đọc và sử dụng vì nó có thể đọc được bằng máy trước khi được hiển thị ở dạng HTML hoặc kiểu khác.
Rest và REST API
Theo thời gian, nhiều phương pháp truyền dữ liệu đã phát triển. Bạn có thể đã bắt gặp các lựa chọn như CORBA, SOAP hoặc XML-RPC. Hướng dẫn tin nhắn nghiêm ngặt nhất được phát triển. Roy Fielding lần đầu tiên phác thảo REST vào năm 2000, điều này đơn giản hơn nhiều so với những cái khác.
Nó là tập hợp các đề xuất và giới hạn cho các dịch vụ web RESTful chứ không phải là một tiêu chuẩn. Chúng bao gồm các ràng buộc kiến trúc sau:
Phân vùng Client-Server
Máy khách và máy chủ web chỉ có thể giao tiếp theo một hướng trong kiến trúc REST: máy khách yêu cầu bộ điều khiển miền và bộ điều khiển hoặc máy chủ đáp ứng yêu cầu. Máy chủ web không thể gửi yêu cầu và khách hàng không thể phản hồi; người tiêu dùng bắt đầu tất cả các kết nối.
Các dịch vụ web RESTful giữ cho khách hàng và máy chủ bị cô lập bằng cách giảm bớt sự tương tác giữa chúng. Máy khách có thể phát triển mà không sợ ảnh hưởng đến máy chủ lưu trữ khác và tài liệu máy chủ có thể được thay đổi mà không vô tình ảnh hưởng đến khách hàng.
Giao diện thống nhất
Theo chiến lược này, tất cả các truy vấn và phản ứng phải tuân thủ quy trình proweb tiêu chuẩn hoặc định kiểu cho thông điệp của chúng. Các ứng dụng và máy chủ được phát triển bằng nhiều ngôn ngữ lập trình khác nhau hoạt động kém với nhau bằng một bộ trung gian. Giao diện thống nhất là một phương ngữ mà bất kỳ khách hàng nào cũng có thể sử dụng để tương tác với bất kỳ API REST nào.
Chỉ có thể dịch các yêu cầu và phản ứng giữa các ứng dụng với tương tác chuẩn hóa. Những khác biệt nhỏ sẽ làm xáo trộn và mất thông tin, đồng thời các giải pháp sẽ phải nâng cấp quy trình yêu cầu của chúng khi API web sửa đổi quy trình của chúng. Một giao diện nhất quán sẽ loại bỏ triển vọng này.
TRUY CẬP VÀO https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Giống như tất cả các ứng dụng Máy khách REST, đề xuất này bao gồm hai phần dữ liệu. Kỹ thuật HTTP là GET. Điều này mô tả hành động mà khách hàng muốn thực hiện trên các tài nguyên. Người dùng có thể tạo bốn phương thức HTTP cơ bản:
HTTP, hay Giao thức truyền siêu văn bản, là ngôn ngữ chung cho hầu hết các API REST. HTTP không được thiết kế dành cho REST. Ngoài ra, REST chấp nhận việc truyền dữ liệu này làm tiêu chí cho các ứng dụng nhận biết REST. Để sử dụng HTTP với API REST, khách hàng gửi yêu cầu ở định dạng mà bạn có thể quen thuộc. Ví dụ: một tín hiệu video yêu cầu API YouTube trông giống như sau:
- Sử dụng lệnh GET để lấy tài nguyên.
- Sử dụng lệnh POST để tạo tài nguyên mới
- Sử dụng lệnh PUT để thay đổi hoặc tiếp tục cập nhật tài nguyên hiện có
- Sử dụng yêu cầu XÓA để loại bỏ tài nguyên.
Các phương thức HTTP chỉ định hành động dự định sẽ được thực hiện liên quan đến một tài nguyên cụ thể. Phương thức HTTP còn được gọi là động từ HTTB.
URL là HTTP
Mã định danh tài nguyên thống nhất hoặc URI xác định tài nguyên dự định được chứa trong URL. URL cũng là một điểm cuối trong trường hợp này vì đó là nơi API RESTful tiếp xúc với người dùng dịch vụ.
Chuỗi truy vấn: URL bao gồm một chuỗi truy vấn. Chuỗi truy vấn được sử dụng để xác định các tham số, được cung cấp các giá trị.
Sau khi nhận và xác minh yêu cầu, máy chủ web sẽ hoàn nguyên dữ liệu trên tài nguyên được nhắm mục tiêu. Thông thường, dữ liệu được trả về trong một cấu trúc được gọi là JSON (Ký hiệu đối tượng JavaScript). JSON trình bày tất cả các thành phần của tài nguyên ở định dạng di động mà Con người có thể dễ dàng đọc.
Nguyên tắc của giao diện thống nhất
Giao diện thống nhất phải tuân theo các thông số sau:
HATEOAS: Hypermedia là động cơ của trạng thái ứng dụng
Hypermedia là công cụ đằng sau các dịch vụ web RESTful. Điều này cho thấy rằng hypermedia là tất cả những gì khách hàng muốn hiểu để nhận ra câu trả lời của nhà cung cấp.
- Chỉ URI đầu tiên của ứng dụng khách phải được cung cấp cho khách hàng. Ứng dụng khách phải liên tục điều khiển tất cả các tài liệu và hoạt động khác bằng cách sử dụng các siêu liên kết.
- Các dịch vụ web RESTful không yêu cầu ngôn ngữ truy vấn đầu vào (IDL), ngôn ngữ này khác với các API khác
Loại phương tiện là tên cho định dạng dữ liệu của biểu diễn. Loại phương tiện xác định một định nghĩa phác thảo cách xử lý mô tả. API web sử dụng REST có vẻ giống như siêu văn bản. Mọi mục dữ liệu có thể được xử lý đều mang một vị trí, trực tiếp (chẳng hạn như thông qua các thuộc tính nhận dạng và liên kết) hoặc ngầm định (ví dụ: bắt nguồn từ cấu trúc mô tả loại phương tiện).
Tin nhắn tự mô tả
Mỗi giao tiếp giữa phía máy khách và phía máy chủ phải cung cấp đủ dữ liệu để thực hiện giao tiếp. Theo đó, yêu cầu từ phía máy khách đến phía máy chủ cần chỉ định tài nguyên mà nó đang cố gắng truy cập cùng với các mục tiêu cụ thể của nó.
Ngoài ra, các mô tả tài nguyên phải tự mô tả; người dùng không cần phải biết tài nguyên là người hay thiết bị. Thay vào đó, nó sẽ phản hồi theo loại phương tiện được kết nối với trợ giúp.
Do đó, không thể chối cãi, chúng tôi sẽ phát triển nhiều loại phương tiện độc đáo, thường là một loại phương tiện cho mỗi tài nguyên. Mọi hình thức truyền thông chỉ định một mô hình sản xuất tiêu chuẩn. Chẳng hạn, HTML xác định cách hiển thị siêu văn bản và cách trình duyệt xử lý từng thành phần.Xác định các nguồn lực
Các tài nguyên được đề cập trong giao tiếp phía sau giữa khách hàng và máy chủ phải được nhận dạng bằng cách sử dụng các mô tả. Bám sát hệ thống Mã định danh tài nguyên thống nhất (URI) cho phép điều này. Nói cách khác, giao tiếp từ máy chủ đến khách hàng có thể bao gồm phiên bản HTML của tài liệu và một số thông tin thay vì tệp thực từ bộ lưu trữ của máy chủ.
Người tiêu dùng có thể dễ dàng hiểu phiên bản HTML vì nó tuân theo mẫu URI. Khách hàng phải sửa đổi tài nguyên bằng cách cung cấp cho máy chủ mô tả về cách cuối cùng tài nguyên sẽ xuất hiện. Điều này sẽ cho phép người dùng xây dựng, truy xuất, sửa đổi và xóa tài nguyên. Nếu khách hàng có quyền cần thiết để thay đổi dữ liệu, máy chủ sẽ thực hiện truy vấn.
không quốc tịch
Với API RESTful, tất cả các yêu cầu của khách hàng phải tạm thời. Do đó, mỗi nội dung truy vấn và phản hồi bao gồm tất cả dữ liệu cần thiết để ký kết hợp đồng, làm cho mỗi kết nối trở nên độc lập. Máy chủ không theo dõi các yêu cầu HTTP trước đó; nó coi mỗi truy vấn do khách hàng thực hiện là một truy vấn hoàn toàn mới.
Vì máy chủ không phải thực hiện bất kỳ tác vụ bổ sung nào để lấy dữ liệu lịch sử, nên việc vận chuyển không trạng thái giảm thiểu đáng kể dung lượng lưu trữ cần thiết cho máy chủ và tăng khả năng chấp nhận phản hồi. Điều này đảm bảo khả năng mở rộng của các tương tác này: các lập trình viên không cần phải lo lắng về việc sử dụng nhiều bộ nhớ hơn hoặc đánh thuế máy chủ khi phần mềm của họ mở rộng và thực hiện các yêu cầu HTTP.
nhiều lớp
Cho đến nay, chúng tôi đã xác định các truy vấn API web là một trao đổi máy khách-máy chủ đơn giản, mặc dù điều này hơi đơn giản hóa một chút. Giữa hai tổ chức này thường có nhiều máy chủ hơn. Các nền tảng hoặc các lớp này được thiết lập để quản lý và phân tán lưu lượng truy cập, thêm lớp bảo vệ và thực hiện nhiều tác vụ quan trọng khác.
Theo khái niệm này, các thông báo được gửi giữa người dùng và máy chủ mục tiêu phải được cấu trúc và xử lý tương tự nhau, bất kể các lớp tồn tại ở giữa. Các lớp bổ sung sẽ phù hợp với các tương tác của khách hàng. Các lập trình viên tuân thủ quy tắc này có thể thay đổi hệ thống máy chủ mà không ảnh hưởng đến quy trình phản hồi yêu cầu cơ bản.
Có thể lưu vào bộ nhớ đệm
Bộ nhớ đệm xảy ra khi khách hàng duyệt một trang web khi nội dung được lưu trên máy của khách hàng. Tài liệu được lưu trong bộ nhớ cache được tải nhanh chóng từ bộ nhớ trong thay vì được tải xuống lại từ máy chủ khi người dùng truy cập trang web đó sau. Hầu hết các trang web lớn đều sử dụng bộ nhớ đệm để giảm tải trang đồng thời tiết kiệm không gian và băng thông máy chủ.
Bộ nhớ đệm dữ liệu được xem xét khi phát triển API REST. Phản hồi mà máy chủ đưa ra cho khách hàng phải nêu rõ tài nguyên đã cho có thể được lưu trữ hay không và khoảng bao lâu.
Trong mã yêu cầu
Nguyên lý REST cuối cùng là không cần thiết. Nếu được yêu cầu, phản hồi của API có thể bao gồm mã phần mềm để khách hàng sử dụng. Do đó, khách hàng có thể thực thi ứng dụng hoặc chương trình khách trong phần phụ trợ của nó.
API được coi là API RESTful nếu nó tuân thủ bộ nguyên tắc này. Tuy nhiên, những nguyên tắc này cho phép các lập trình viên tự do sửa đổi các tính năng của API RESTful của họ. API REST khác với Giao thức truy cập đối tượng đơn giản, một kỹ thuật API web phổ biến khác, ở chỗ chúng linh hoạt hơn (SOAP).
Đồng thuận điểm cuối
Hãy tính đến các điểm cuối này:
- /người dùng/123\s
- /người dùng/id/123\s
- /user/123\s/user/id/123\s
- /người dùng/?id=123
Tất cả đều là phương pháp hợp pháp để khách hàng 123 lấy dữ liệu. Khi có nhiều thủ tục phức tạp hơn, số lượng khả năng tăng lên. Chẳng hạn, theo thứ tự ngược lại bắt đầu từ mục 51, hãy hiển thị 10 người có họ bắt đầu bằng chữ "A" và hoạt động cho công ty.
Cuối cùng, nó không quan tâm đến cách bạn cấu trúc URL; tính đồng nhất trong suốt các vấn đề API RESTful của bạn. Trên các hệ thống phần mềm khổng lồ với nhiều lập trình viên, điều đó không thể dễ dàng. Việc sửa đổi API RESTful là không thể tránh khỏi, nhưng các URL điểm cuối không bao giờ được từ chối vì làm như vậy sẽ khiến các ứng dụng dựa vào chúng ngừng hoạt động.
Phiên bản API REST
Phiên bản API là một phương pháp phổ biến để ngăn chặn sự không tương thích. Để minh họa, /2.0/user/123 thay thế /user/123. Các điểm cuối cũ và mới đều có thể tiếp tục hoạt động. Do đó, điều này buộc phải duy trì các API quan trọng trong quá khứ. Các phiên bản trước cuối cùng có thể bị loại bỏ, nhưng quy trình cần được suy nghĩ cẩn thận.
Xác thực API REST
Bất kỳ thiết bị nào cũng có thể tải xuống câu đố mà không cần ủy quyền bằng cách sử dụng API truy vấn. API đọc thông tin cá nhân hoặc cho phép chỉnh sửa và xóa truy vấn không hỗ trợ điều này. Các chương trình phía máy khách trong cùng một miền với các dịch vụ web RESTful được gửi và nhận cookie giống như các yêu cầu HTTP. (Xin lưu ý rằng tùy chọn khởi động lại đặc quyền phải được chỉ định trong các trang web trước đó cho Tìm nạp().) Có thể xác minh truy vấn API để xác nhận rằng người dùng đã đăng nhập và có các quyền cần thiết.
Xác thực cơ bản HTTP : Các chương trình của bên thứ ba phải sử dụng các giải pháp phê duyệt khác nhau. Một số phương pháp xác thực phổ biến là xác minh chính cho:
- HTTP. Chuỗi tên người dùng: mật khẩu được mã hóa base64 được cung cấp trong trường truy vấn như một phần của tiêu đề Phê duyệt HTTP.
- Khóa API: Bằng cách cung cấp khóa API RESTful có thể có quyền đặc biệt hoặc bị giới hạn ở một trang web, API được cung cấp cho các ứng dụng của bên thứ ba. Mỗi thông báo chứa khóa trên chuỗi truy vấn hoặc trong tiêu đề HTTP. (Chuỗi truy vấn là một thành phần của URL).
- OAuth: Trước khi thực hiện bất kỳ yêu cầu nào, ID khách hàng và có thể là bí mật của khách hàng sẽ được gửi đến máy chủ OAuth để lấy thông tin xác thực. Cho đến khi hết hạn, danh tính OAuth sau đó sẽ được truyền cùng với mỗi yêu cầu API.
- Mã thông báo Internet ở dạng JSON (JWT): Tiêu đề truy vấn và tiêu đề phản hồi truyền tải thông tin xác thực người dùng được ký điện tử một cách an toàn. JWT cho phép máy chủ mã hóa các đặc quyền truy cập, loại bỏ nhu cầu truy vấn cơ sở dữ liệu hoặc sử dụng cơ chế xác thực khác.
Kịch bản sử dụng sẽ ảnh hưởng đến cách API được xác thực:
- Đôi khi, chương trình của bên thứ ba được xử lý giống như bất kỳ ứng dụng khách đã đăng nhập nào khác có cùng đặc quyền và quyền. Chẳng hạn, API bản đồ có thể cung cấp cho chương trình yêu cầu các hướng dẫn giữa hai điểm. Nó phải xác minh rằng chương trình là người dùng hợp pháp, nhưng nó không phải xác minh thông tin đăng nhập của khách hàng.
- Trong các tình huống khác, chương trình của bên thứ ba yêu cầu thông tin cá nhân từ một người dùng cụ thể, chẳng hạn như nội dung thư. API REST phải nhận ra ứng dụng khách và quyền của họ, nhưng chúng không cần quan tâm đến chương trình gọi.
Bảo mật API REST
Các dịch vụ web RESTful bổ sung thêm một cách để tương tác và tác động đến phần mềm của bạn. Ngay cả khi máy chủ lưu trữ của bạn không phải là mục tiêu tấn công nâng cao, người dùng có hành vi sai trái có thể gửi hàng trăm yêu cầu mỗi giây và làm sập nó. Bài viết này không đề cập đến vấn đề bảo mật, nhưng các quy trình tiêu chuẩn tốt nhất liên quan đến:
Tận dụng HTTPS
Sử dụng một cơ chế xác thực mạnh mẽ
CORS có thể được sử dụng để hạn chế các cuộc gọi của khách hàng đến các khu vực cụ thể.
Cung cấp những nhu cầu cần thiết về khả năng — nghĩa là, không
Tạo các lựa chọn XÓA không cần thiết; xác minh tất cả các URL điểm cuối và thông tin nội dung.
Chặn các liên kết từ các khu vực hoặc địa chỉ IP không xác định bằng cách không sử dụng phiếu thưởng API trong JavaScript phía máy khách.
Các gói lớn bất thường bị chặn.
Hãy nghĩ về giới hạn tốc độ, trong đó các yêu cầu từ cùng một địa chỉ IP hoặc thông tin xác thực API bị giới hạn ở N truy vấn mỗi phút.
Phản hồi với mã trạng thái HTTP phù hợp, truy vấn nhật ký tiêu đề bộ đệm và điều tra không thành công
Nhiều yêu cầu và dữ liệu không cần thiết
Việc triển khai các dịch vụ web RESTful có những hạn chế. Có thể một phản hồi có nhiều thông tin hơn bạn yêu cầu hoặc nhiều yêu cầu được yêu cầu để có được tất cả thông tin. Hãy nghĩ về các dịch vụ web RESTful cung cấp cho người dùng quyền truy cập vào thông tin về sách và tác giả; khách hàng có thể:
- Yêu cầu thông tin về 10 cuốn sách đầu tiên, được liệt kê theo thứ tự mua (bán chạy nhất trước). Một bộ sưu tập sách, cùng với ID của mỗi nhà văn, được bao gồm trong câu trả lời.
Để truy xuất thông tin cho mỗi người viết, hãy tạo tối đa 10 truy vấn /tác giả/id.
N truy vấn API phải được tạo cho mỗi phản hồi đối với truy vấn gốc, được đặc trưng là "N+1 vấn đề".
Nếu đây là trường hợp sử dụng thường xuyên, các dịch vụ web RESTful có thể được sửa đổi để bao gồm tất cả thông tin về người viết cho mọi cuốn sách mà nó sản xuất, bao gồm tên, giới tính, quốc tịch, tiểu sử, v.v. Thậm chí nhiều thông tin hơn về các cuốn sách trước đây của họ có thể được cung cấp, mặc dù làm như vậy sẽ làm tăng đáng kể gánh nặng phản hồi. API có thể được thay đổi để làm cho thông tin người viết trở thành tùy chọn. Chi tiết tác giả=đầy đủ để tránh những câu trả lời lớn không cần thiết. Số lượng tùy chọn tuyệt đối mà các nhà thiết kế API phải hỗ trợ có thể khiến bạn choáng ngợp.
kết thúc
Giờ đây, bạn đã hiểu rõ về API REST, cách thức hoạt động của API REST, các ví dụ về API REST, API REST được sử dụng để làm gì, các ràng buộc về kiến trúc và các chủ đề khác được đề cập trong hướng dẫn này. Các lập trình viên có thể thấy việc tìm hiểu về API khó khăn và đáng sợ, nhưng nền tảng không mã AppMaster đã tạo một thư viện API REST có thể truy cập mới, nơi bạn có thể nâng cao nhận thức của mình về một loạt API REST để hỗ trợ sự phát triển chuyên nghiệp hơn nữa của bạn.
Tại AppMaster, chúng tôi cố gắng tăng khả năng tiếp cận và sử dụng API. Chúng tôi muốn bạn tìm hiểu, thử nghiệm và nhận ra lợi ích của việc sử dụng phần mềm API trong sự nghiệp và cuộc sống cá nhân của bạn. Để giúp bạn thiết kế các API web tốt hơn nhanh hơn, AppMaster cải thiện khả năng cộng tác và tự động hóa mọi giai đoạn của vòng đời API. Tiếp tục tạo, nâng cao và mở rộng hiểu biết của bạn về API REST.
