Yêu cầu API bên ngoài

Không quá nhiều lý thuyết?

Hãy đưa điều này vào thực tế. Hãy mở AppMaster , tạo một yêu cầu API bằng cách sử dụng nó và hiểu rõ hơn về cách thức hoạt động của yêu cầu này.

Tạo yêu cầu API bên ngoài

Các yêu cầu API được tạo trong phần “Logic nghiệp vụ”, trong tab “Yêu cầu API bên ngoài”.

Đã đến lúc nhấp vào “+ Yêu cầu API mới”

Tên và mô tả có thể được đặt thành bất kỳ thứ gì, chúng chỉ dành cho mục đích sử dụng cá nhân của chúng tôi.

Hãy xử lý dữ liệu thực sự quan trọng.

Yêu cầu tối thiểu để tạo một yêu cầu là chỉ định Phương thức và địa chỉ (URL) của nó. Hãy bắt đầu với cái cuối cùng.

URL

URL - Bộ định vị tài nguyên thống nhất. Một địa chỉ được cung cấp cho một tài nguyên cụ thể trên Internet. Phiên bản quen thuộc nhất của tài nguyên như vậy là trang HTML - chúng tôi nhập URL của nó vào thanh địa chỉ của trình duyệt và mở trang web mong muốn. Đồng thời, bản thân tài nguyên có thể là bất kỳ thứ gì, ảnh, video, tập dữ liệu. Điều chính là tài nguyên này có một con trỏ cụ thể - một URL mà bạn có thể gửi yêu cầu để lấy tài nguyên này.

phương pháp

Đề cập đến dữ liệu tại địa chỉ của nó, chúng tôi cũng chỉ ra phương thức (bạn cũng có thể nói loại) của yêu cầu, tức là chúng tôi chỉ ra những gì thực sự cần phải làm với dữ liệu này.

Khi chúng tôi gửi yêu cầu cho nhiệm vụ của mô-đun đầu tiên, chúng tôi đã nhận được dữ liệu. Đây là phương thức NHẬN. Phương pháp này là phương pháp rõ ràng nhất và cũng là phương pháp bắt buộc duy nhất. Do đó, ngay cả khi chúng tôi không chỉ định nó một cách rõ ràng, thì theo mặc định, nó vẫn được mặc định rằng đây là GET.

Hãy xem những phương pháp khác tồn tại.

Bản thân tiêu chuẩn HTTP không giới hạn số phương thức có thể được sử dụng. Đồng thời, chỉ một số phương pháp tiêu chuẩn nhất vẫn được sử dụng để duy trì khả năng tương thích. Có 5 phương pháp khác nhau có thể được sử dụng trong yêu cầu API AppMaster.

NHẬN . Nó đã được xử lý. Phương thức yêu cầu cung cấp tài nguyên và nhận dữ liệu.

ĐĂNG . Để lấy dữ liệu từ một nơi nào đó, trước tiên bạn cần đặt dữ liệu này ở đó. Phương thức POST thực hiện điều đó. Gửi dữ liệu đến máy chủ, tạo tài nguyên.

ĐẶT . Tương tự như phương thức POST, nhưng công việc của nó là cập nhật dữ liệu. Nó không tạo dữ liệu mới mà thay thế dữ liệu hiện có, cập nhật dữ liệu đó.

XÓA . Như tên cho thấy, nó xóa dữ liệu.

VÁ . Phương pháp này tương tự như PUT, nhưng được sử dụng để cập nhật một phần dữ liệu, thay vì thay thế hoàn toàn. Ví dụ: sử dụng phương thức PATCH, bạn có thể thay đổi tiêu đề của một bài báo hoặc thay đổi giá trị của một số tham số.

Điều quan trọng là phải xem xét thực tế là máy chủ không bắt buộc phải thực hiện chính xác những gì được chỉ định trong phương thức. Chúng ta có thể gửi địa chỉ của một số trang bằng phương thức DELETE, nhưng điều này không có nghĩa là máy chủ sẽ thực sự xóa nó. Tuy nhiên, hoàn toàn về mặt lý thuyết, anh ta có thể làm điều này bằng lệnh GET. Hoặc không thay đổi bất cứ điều gì, nhưng đồng thời gửi dữ liệu để phản hồi POST. Chỉ vì nhà phát triển đã cấu hình nó theo cách đó.

Đây là lúc REST phát huy tác dụng, điều này nói rằng đã đến lúc phải thống nhất về việc tuân thủ mệnh lệnh, ngăn chặn sự lộn xộn và thực hiện chính xác những gì được chỉ định trong phương thức. Ít nhất, đây phải là nhiệm vụ chính (mặc dù không nhất thiết là nhiệm vụ duy nhất). Ví dụ: khi truyền nội dung của một bài viết bằng phương thức GET, bạn có thể đồng thời tăng bộ đếm số lượt xem của bài viết đó lên 1.

Vì vậy, chúng tôi đã tìm ra vị trí của dữ liệu và những gì có thể được thực hiện với nó. Hãy đi xa hơn, hãy xem yêu cầu có thể có những thành phần nào khác.

Thông số URL

Thông số URL . Có những trường hợp chúng tôi chỉ biết một phần của URL. Một ví dụ là các bài viết trên trang web Appmaster.io. Địa chỉ bắt đầu cho tất cả các bài viết đều giống nhau - https://appmaster.io/blog/ . Nhưng sau đó, mỗi bài viết có tiêu đề riêng và theo đó, phần riêng của nó để chỉ dẫn chính xác bài viết cụ thể này.

Trong tình huống như vậy, Thông số URL được sử dụng. Chúng tôi quy định phần chung ngay lập tức và để phần còn lại được quyết định trong quá trình này. Do đó, URL được viết ở dạng https://appmaster.io/blog/:id/

Phần đã biết được viết nguyên trạng và phần biến được đặt sau dấu “:”. Tên của phần biến này (đã không có “:”) được thêm vào danh sách tham số. Trong trường hợp này, có thể có một số phần thay đổi và vị trí của chúng ở bất kỳ đâu trong URL.

Tham số truy vấn

Tham số truy vấn . Bạn có nhớ khi chúng tôi gửi yêu cầu tới trang chánapi.com trong mô-đun đầu tiên không? Và ngoài địa chỉ, dữ liệu bổ sung đã được quy định. Đó là Thông số truy vấn.

Chúng được viết sau URL và được phân tách với nó bằng dấu “?” dấu hiệu. Tên của tham số, dấu “=” và giá trị của chính tham số được chỉ định. Nếu một số tham số được sử dụng cùng một lúc, chúng được phân tách bằng dấu “&”.

Tuy nhiên, khi chỉ định tham số trong AppMaster, bạn không cần phải suy nghĩ về các quy tắc yêu cầu. Mọi thứ sẽ được định dạng đúng cách tự động. Bạn chỉ cần chỉ định tên của tham số và thêm nó vào danh sách.

Tham số truy vấn được sử dụng khi nguồn dữ liệu giống nhau, nhưng bản thân dữ liệu có thể khác. Ví dụ, Boredapi chứa một danh sách khổng lồ những việc cần làm. Nhưng chúng tôi chỉ quan tâm đến những thứ dành cho một người và đó là những gì chúng tôi đã chỉ định trong các tham số yêu cầu.

Một trường hợp sử dụng khác là giới hạn lượng dữ liệu. Ví dụ: chúng tôi có thể truy cập một số danh sách nhưng chỉ yêu cầu 5 mục nhập đầu tiên từ danh sách đó. Số lượng này cũng có thể là một tham số truy vấn.

Một tùy chọn khác là khóa truy cập. Bạn có thể đã sử dụng tùy chọn này trong mô-đun 1 khi tham khảo Alphavantage. Dữ liệu chỉ có thể được lấy sau khi đăng ký và gửi khóa cá nhân trong các tham số yêu cầu.

Hãy chú ý đến các trang mà bạn truy cập trên Internet, có thể bạn cũng sẽ tìm thấy nhiều thông số khác nhau trong đó. Ví dụ: mở trang thời tiết của Ventusky.com, trong các tham số truy vấn, các giá trị địa lý của vĩ độ và kinh độ được gửi.

tiêu đề

Tiêu đề . Yêu cầu tiêu đề. Thông thường các tiêu đề chứa thông tin dịch vụ về yêu cầu (thông tin meta). Tiêu đề cho phép máy chủ nhận thêm thông tin về máy khách đang yêu cầu dữ liệu. Các tiêu đề có thể chứa thông tin về trình duyệt nào đang được sử dụng, mã hóa phản hồi dự kiến ​​sẽ ở dạng nào, bằng ngôn ngữ nào, thời gian chính xác của yêu cầu, v.v. Trong trường hợp truy cập vào dữ liệu được bảo vệ, các tiêu đề có thể chứa khóa ủy quyền.

Trong hầu hết các trường hợp, tiêu đề là tùy chọn. Ngay cả trong mô-đun đầu tiên, chúng tôi đã thực hiện một yêu cầu mà chúng tôi không chỉ định bất kỳ tiêu đề nào (mặc dù điều này không có nghĩa là yêu cầu thực sự được gửi mà không có chúng).

Thân hình

Cơ thể . Yêu cầu cơ thể. Các yêu cầu GET thường không có nó, nhưng nếu chúng ta muốn gửi một số dữ liệu đến máy chủ, hãy gửi một yêu cầu POST hoặc PUT, thì dữ liệu này sẽ được đặt trong phần thân yêu cầu. Đồng thời, bạn có thể đặt dữ liệu có độ phức tạp bất kỳ trong phần thân yêu cầu, chẳng hạn như gửi tệp video và không bị giới hạn ở một số hoặc một chuỗi văn bản.