Swagger là một công cụ đặc biệt tự động soạn tài liệu RESTful API cho ứng dụng của bạn.

Ưu điểm của nó nằm ở chỗ nó cho phép bạn không chỉ xem qua tất cả các điểm cuối của ứng dụng mà còn có thể ngay lập tức kiểm tra hoạt động của chúng bằng cách gửi yêu cầu và nhận phản hồi.

Để truy cập Swagger , bạn cần nhấn vào nút Preview trong ứng dụng đã xuất bản và nhấp vào tên của kế hoạch xuất bản được yêu cầu ( Deploy Plan ).

swagger access

Trong cửa sổ mới mở, danh sách các điểm cuối có sẵn và các phương thức được liên kết với các điểm cuối này được hiển thị. Một số yêu cầu chỉ khả dụng cho một số nhóm người dùng được ủy quyền nhất định (xem Phần mềm trung Middleware của Auth module thực cho từng yêu cầu cụ thể trong phần Endpoints ). Cần có Bearer Token thông báo mang cho các yêu cầu chỉ được phép cho người dùng được ủy quyền.

Bạn có thể truy cập trực tiếp vào điểm cuối tương ứng trong Swagger để nhận mã thông báo này ( phần Auth thực, yêu cầu POST /auth ).

swagger authorize

Nhấn Try it out và nhập thông tin đăng nhập và mật khẩu để nhận mã thông báo.

Yêu cầu sẽ được gửi trên Execute . Nếu thành công, bạn sẽ thấy trường token thông báo có giá trị Bearer token .

Cách thứ hai để nhận mã thông báo người dùng được ủy quyền là mã thông báo có thể được tìm thấy trong phần yêu cầu của ứng dụng đã triển khai.

  1. Nhấn F12 trong trình duyệt web của bạn để mở công cụ của nhà phát triển.
  2. Gửi bất kỳ yêu cầu nào trong ứng dụng đã triển khai của bạn (ví dụ: để cập nhật các bảng). Người dùng đang gửi yêu cầu này phải được ủy quyền để truy cập điểm cuối này.
  3. Mở tab Network và tìm yêu cầu tương ứng.
  4. Chuyển đến tab Headers và tìm phần Request Headers . Bearer token sẽ được trình bày dưới Authorization .

bearer token

Cung cấp Bearer token cho Swagger bằng cách nhấn Authorize và dán giá trị bạn đã sao chép ở bước trước.

Đối với các yêu cầu thử nghiệm, hãy chọn nhóm mong muốn và phương pháp bạn muốn thực hiện. Nhấn Try it out và điền các thông số đầu vào yêu cầu. Nhấp vào Execute để thực hiện phản hồi.

Phản hồi được mong đợi nhất, nếu yêu cầu được máy chủ xử lý chính xác, có mã 200 và hiển thị cấu trúc phản hồi sẽ như thế nào.

response 200

  • 401 - yêu cầu không được hoàn tất thành công vì mã thông báo ủy quyền bắt buộc bị thiếu hoặc không hợp lệ.

    response 401

  • 404 - yêu cầu đã được xử lý thành công nhưng không tìm thấy tài nguyên được yêu cầu.

    response 404

  • 422 - thông số không chính xác đã được chuyển đến đầu vào của yêu cầu.

    response 1200

  • 500 - lỗi xử lý yêu cầu của máy chủ.

    response 500

Tăng lỗi tùy chỉnh

Đối với các BP tùy chỉnh và các yêu cầu liên quan, có thể tạo mã lỗi tùy chỉnh với các mô tả bằng cách sử dụng khối Raise Error trong trình chỉnh sửa BP. Một ví dụ về quá trình như vậy là dưới đây:

example

Trong trường hợp này, nếu yêu cầu đến điểm cuối được liên kết với BP ở trên không thành công, máy chủ sẽ đưa ra lỗi 418 có chứa văn bản lỗi khi thực hiện khối DB: Create Candidate block . Mã lỗi trong ví dụ này có thể là bất kỳ mã nào mà người dùng chỉ định.

Lưu ý: mã phản hồi lỗi HTTP 418 I'm a teapot client cho biết rằng máy chủ từ chối pha cà phê vì nó vĩnh viễn là một ấm trà. Thay vào đó, bình cà phê/trà kết hợp tạm thời hết cà phê sẽ trả về 503. Lỗi này liên quan đến Hyper Text Coffee Pot Control Protocol được xác định trong trò đùa Cá tháng Tư năm 1998 và 2014.

Was this article helpful?

AppMaster.io 101 Khóa học tai nạn

10 Mô-đun
2 Tuần

Không biết chắc nên bắt đầu từ đâu? Bắt đầu với khóa học sụp đổ của chúng tôi dành cho người mới bắt đầu và khám phá AppMaster từ A đến Z.

Bắt đầu khóa học
Development it’s so easy with AppMaster!

Cần sự giúp đỡ nhiều hơn?

Giải quyết mọi vấn đề với sự giúp đỡ của các chuyên gia của chúng tôi. Tiết kiệm thời gian và tập trung vào việc xây dựng các ứng dụng của bạn.

headphones

Liên hệ hỗ trợ

Hãy cho chúng tôi biết về vấn đề của bạn và chúng tôi sẽ tìm ra giải pháp cho bạn.

message

trò chuyện cộng đồng

Thảo luận câu hỏi với những người dùng khác trong cuộc trò chuyện của chúng tôi.

Tham gia cộng đồng