Đưa API của bạn vào sản xuất

Khi bạn thực hiện tìm kiếm trên web về “cách xây dựng API”, tôi thấy rằng có khá nhiều tùy chọn xuất hiện, nhưng rất ít là hướng dẫn từ đầu đến cuối. Điều này có thể là do khả năng tìm kiếm trên web của tôi kém hoặc vì việc xây dựng một API khá khó khăn (đưa nó từ thiết kế đến sản xuất). Bất kỳ ai làm việc với API sẽ cho bạn biết rằng nó có thể khá kỳ công và một nhóm người thường quản lý nó. Vì vậy, việc tự xây dựng một API và đưa nó vào sản xuất để người dùng của bạn có thể bắt đầu sử dụng nó có thể là một thách thức đáng kể.

Chúng ta đang sống trong một thời kỳ may mắn khi có rất nhiều công cụ giúp cho công việc này trở nên dễ quản lý hơn nhiều. Với một cái gì đó như Postman, chúng tôi có thể tạo đặc tả API, kiểm tra đặc tả API và cuối cùng là kiểm tra API của chúng tôi để đảm bảo rằng nó đang hoạt động như mong đợi. Để xây dựng phần cuối cho API của chúng tôi, chúng tôi sẽ cần một loạt các công cụ như Flask, Heroku, v.v. hoặc chúng tôi có thể chọn một công cụ mã thấp để xây dựng và lưu trữ API của chúng tôi.

Trong bài đăng này, chúng ta sẽ xem xét quá trình xây dựng một API và cách quá trình này có thể được thực hiện hiệu quả hơn.

Quy trình phát triển API

Việc phát triển API rất phức tạp, không có cách nào xung quanh nó. Thông thường, chúng tôi cần thiết kế API, viết mã, kiểm tra, gỡ lỗi, viết lại mã, kiểm tra thêm một số thứ nữa, triển khai khi chúng tôi sẵn sàng và sau đó là bảo trì dường như vô tận. Vòng đời phát triển API điển hình sẽ giống như sau:

Mỗi bước trong quy trình thường sẽ được thực hiện bởi một công cụ hoặc tài nguyên khác, vì vậy nó có thể trở thành một nỗ lực khá lớn để triển khai một API. Ví dụ: chúng tôi có thể chọn sử dụng Postman để thiết kế API của chúng tôi (Đặc điểm kỹ thuật API mở) và sử dụng một cái gì đó như flask cho mã kết nối firebase của chúng tôi hoặc một số cơ sở dữ liệu để lưu trữ hoặc truy xuất dữ liệu của chúng tôi. Chúng tôi cũng có thể cần thực hiện các lệnh gọi REST bổ sung tới các API và dịch vụ khác. Để kiểm tra, chúng tôi có thể sử dụng lại Postman, nhưng việc gỡ lỗi mã và tất cả các trình kết nối của chúng tôi có thể trở nên rắc rối. Để triển khai, chúng tôi có thể chọn Heroku, nhưng nó phụ thuộc vào những gì API của chúng tôi yêu cầu. Để giám sát, chúng tôi có thể tạo hệ thống giám sát của mình hoặc sử dụng một cái gì đó như Splunk. Và khi chúng ta cần duy trì API của mình, chúng ta cần tìm hiểu lại tất cả những điều đó. Bạn hiểu những gì tôi đang cố gắng nói. Phát triển API rất phức tạp.

Tìm một cách tốt hơn

Tôi muốn một cách để đơn giản hóa vòng đời phát triển API và phát triển các API của mình từ thiết kế đến sản xuất chỉ với đầy đủ các công cụ. Nhờ các công cụ mã thấp như Linx, điều này có thể thực hiện được. Tôi đã có thể tạo một API, từ thiết kế đến triển khai, chỉ bằng ba công cụ:

• Người đưa thư Tôi đã sử dụng người đưa thư để tạo đặc tả API của mình (dựa trên YAML) và để kiểm tra API của mình
• Linx tôi đã sử dụng để xây dựng API của tôi, triển khai logic, gỡ lỗi nó và cuối cùng là lưu trữ nó. Lưu ý nhanh, bạn cũng có thể thử xây dựng một API với hướng dẫn có hướng dẫn này.
• SQL Server SQL Server được sử dụng để lưu trữ dữ liệu cho API của tôi. Tôi đã sử dụng cơ sở dữ liệu AdventureWorks2019 được tạo trước và dữ liệu của nó.

Yêu cầu

Tôi đã chọn một API đơn giản sẽ thực hiện bảo trì hồ sơ người dùng. API có năm phương pháp:

Tạo đặc điểm kỹ thuật

Tôi đã tạo một đặc tả API đơn giản trong Postman bằng cách sử dụng YAML phù hợp với yêu cầu. Postman cho phép tôi xem những gì tôi đã tạo và cung cấp thông tin bổ sung một cách trực quan. Tạo định nghĩa API trong Postman cũng có lợi khi nó đã thiết lập API đó để thử nghiệm. Nếu bạn chọn, bạn có thể thiết lập các tập lệnh thử nghiệm ở giai đoạn này.

Xây dựng API

Bây giờ tôi đã có định nghĩa API, mã có thể được tạo. Linx cho phép bạn nhập đặc tả OpenAPI 3.0 và sẽ tự động tạo các sự kiện cho từng phương pháp được chỉ định. Tôi chỉ cần xác định URI và sau đó xây dựng logic.

Việc tạo logic của mỗi sự kiện diễn ra tương đối nhanh chóng sau khi plugin cơ sở dữ liệu được cài đặt. Linx có một đường cong học tập giống như mọi công cụ, nhưng một khi bạn hiểu cách làm việc với nó, tốc độ sẽ tăng lên. Tôi đã thêm logic và chức năng vào từng sự kiện cho API. Ví dụ, đối với phương thức GetAllUsers, tất cả chúng ta cần đọc từ cơ sở dữ liệu SQL và trả về kết quả thông qua phần thân phản hồi.

Kiểm tra API

Vì API đã được thiết lập trên Postman nên việc kiểm tra theo thời gian thực khá dễ dàng, API hoạt động như thế nào khi logic đã được triển khai. Ảnh GIF bên dưới cho thấy cách tôi đã sử dụng trình thiết kế Linx để gỡ lỗi API REST mà tôi đã tạo và cách tôi đang kiểm tra nó trong chế độ gỡ lỗi.

GIF

Với API đang được gỡ lỗi trong Linx, nó đang được lưu trữ để tôi có thể gọi nó để xem nó sẽ hoạt động như thế nào khi tôi triển khai. Điều này cho phép tôi kiểm tra và nhận lại kết quả thực tế:

Tất nhiên, chúng tôi cũng có thể thêm các tập lệnh thử nghiệm trong Postman để tự động hóa quy trình thử nghiệm của mình. Các tập lệnh này sẽ đảm bảo rằng bạn đang nhận được phản hồi chính xác.

Triển khai API

Bây giờ API đã được thiết kế, phát triển và thử nghiệm, nó cần được triển khai. Đây có thể là một nhiệm vụ quan trọng với phát triển API truyền thống vì chúng tôi cần đưa ra chiến lược triển khai, tìm ra nơi chúng tôi sẽ lưu trữ những gì và đảm bảo rằng việc giám sát và ghi nhật ký được quan tâm và hơn thế nữa. Việc triển khai của tôi khá đơn giản. Tôi đã triển khai API từ Linx Designer trực tiếp trên Máy chủ Linx. Mất khoảng 2 phút để giải pháp được xây dựng, đẩy lên máy chủ và sẵn sàng sử dụng. Khó khăn khi lưu trữ một API được loại bỏ khi máy chủ Linx xử lý việc này. Nó cũng thực hiện giám sát và ghi nhật ký:

Tôi đã gọi phương thức GetUser với một ID không chính xác để xem điều gì sẽ xảy ra nếu xảy ra lỗi không mong muốn. Máy chủ ghi lại lỗi và chỉ báo bằng màu đỏ rằng đã xảy ra lỗi:

Tôi đã có thể gọi lại API từ Người đưa thư và máy chủ đưa ra chỉ báo mỗi khi API được gọi. Phải thừa nhận rằng tôi đã không thêm bất kỳ hình thức bảo mật hoặc xác thực nào vào API của mình, nhưng những cài đặt này có sẵn trong trình thiết kế Linx. Một tùy chọn khác mà tôi đã thử là tạo Tài liệu API ở định dạng vênh váo. Điều này hóa ra khá có giá trị vì bằng cách thêm / swagger vào URI cơ sở, tài liệu sẽ có sẵn và được tích hợp sẵn với chính API. Điều này giúp bạn dễ dàng phân phối tài liệu API khi cần thiết.

Kết thúc

Khi kết hợp Linx và Postman, chúng ta có thể thiết kế, tạo, lập tài liệu và lưu trữ các API. Nó cần một chút để làm quen, giống như bất kỳ công cụ nào. Vì Linx sử dụng các mô hình lập trình tiêu chuẩn và biệt ngữ, nên bạn có thể dễ dàng hiểu được nếu bạn đã quen với ngôn ngữ lập trình như C #. Tôi cảm thấy rằng chúng tôi tiết kiệm thời gian nhất khi triển khai và lưu trữ một API với Linx. Việc giám sát và lưu trữ được thực hiện cho bạn, có nghĩa là bạn sẽ phải giải quyết vấn đề đau đầu đáng kể. Nếu việc ghi nhật ký và giám sát không đủ chi tiết, bạn có thể thêm chức năng của mình vào giải pháp Linx. Nếu bạn muốn thử xây dựng một API với Linx, bạn có thể tự mình thử

• sử dụng (với Người đưa thư) hoặc
• (chỉ xây dựng)