Giao diện lập trình ứng dụng, hoặc API, là cách phần mềm này nói chuyện với phần mềm khác. Chúng trừu tượng hóa sự phức tạp của các hệ thống cơ bản để chúng có thể kết nối với nhau theo những cách mới lạ ngay cả khi không bao giờ có ý định tương tác lẫn nhau. Do đó, API là một chìa khóa quan trọng trong cả những trải nghiệm kỹ thuật số hiện đại nhất và những cơ hội kinh doanh thú vị nhất hiện nay.

Tuy nhiên, giá trị mà một API cung cấp không chỉ liên quan đến chức năng và dữ liệu mà API cung cấp quyền truy cập, mà còn cả ở cách API được thiết kế. Nhiều API được thiết kế để tích hợp – nghĩa là, dưới dạng những dự án chỉ kết nối với hệ thống một lần và không dự đoán việc sử dụng API trong tương lai. Nhưng các API có giá trị nhất có xu hướng được thiết kế để giúp công việc của các nhà phát triển trở nên dễ dàng hơn và giúp các nhà phát triển khác sử dụng trong tương lai. Đây chính là thiết kế để tiêu dùng.

Sự khác biệt trên có thể tác động đáng kể đến hiệu quả và khả năng đổi mới của doanh nghiệp. Các API được thiết kế để tiêu dùng làm cho chức năng và dữ liệu có giá trị có thể được tái sử dụng, cho phép các nhà phát triển kết hợp và ghép nối các API khác nhau theo module để tạo ra trải nghiệm kỹ thuật số mới hoặc kích hoạt các chiến lược mới. Đối với các mục tiêu như hợp lý hóa sự tham gia của đối tác hoặc tạo điều kiện tham gia vào hệ sinh thái kỹ thuật số, việc có thể tận dụng các API theo cách này là rất quan trọng.

Ngược lại, các API được thiết kế để tích hợp có thể phục vụ nhu cầu tức thời của một dự án, nhưng không giúp các nhà phát triển làm được nhiều điều với chúng trong tương lai. Các API này có thể không được thiết kế theo cách mà các nhà phát triển trong tương lai dễ dàng hiểu và sử dụng, hay có thể hoạt động theo cách mà các nhà phát triển trong tương lai mong muốn. Điều này có thể dẫn đến việc phải tạo ra các API mới. Có thể tránh công việc mới phát sinh và sự chậm trễ này nếu ngay từ đầu các API cũ được thiết kế với tầm nhìn rộng và xa hơn.

Làm các nào để các nhà thiết kế API đảm bảo rằng họ đang xây dựng các API có thể tối đa hóa giá trị và năng suất của nhà phát triển? Google Cloud đã khai thác chủ đề này nhiều lần trong blog của họ và một số mẹo thiết kế API hữu ích, các phương pháp hay nhất được Google khuyên chính là:

• Nhiều cách tiếp cận khác nhau: REST, RPC, GraphQl

Những gì một API đòi hỏi có thể liên quan đến các cách tiếp cận khác nhau để tương tác với hệ thống và các tiêu chuẩn thiết kế khác nhau, vì vậy việc tổng quan các mô hình thiết kế API khác nhau là một điểm khởi đầu tuyệt vời. Bạn có thể tìm hiểu thêm ở: Thiết kế API: Hiểu về gRPC, OpenAPI, REST và khi nào nên sử dụng chúng, Rest và RPC: Bạn đang muốn giải quyết vấn đề gì bằng API của mình?, GraphQL: Xây dựng phương pháp tiếp cận nhất quán cho người dùng API, và Tại sao API của bạn nên hướng đến thực thể? 

• Tổng quan về thiết kế API

Để có kiến thức tổng quan về thiết kế API, ebook API Web Design: The Missing Link: Best Practices for Crafting. Interfaces that Developers Love của Google sẽ cung cấp nền tảng vững chắc, và Google Cloud API Design Guide – đã được sử dụng bên trong Google từ năm 2014 và là chuẩn thiết kế API đám mây và các API khác của Google. Ngoài ra, bạn có thể đọc thêm API Design Best Practices & Common Pitfalls – một bản tóm tắt các câu hỏi và trả lời về thiết kế API trên phạm vi rộng.

• Những thách thức cụ thể 

Google cũng khám phá nhiều thách thức thiết kế API cụ thể và chi tiết hơn, những điều có thể ảnh hưởng đến giá trị lâu dài của API. Chẳng hạn như, API có nhiều cách xác định mối quan hệ. Trong API của một nhà bán lẻ, mô hình thông tin có thể giải quyết mối quan hệ giữa các thực thể như khách hàng, đơn đặt hàng, mặt hàng trong danh mục, giỏ hàng, v.v. Tương tự, API của ngân hàng cho biết tài khoản thuộc về khách hàng nào hoặc tài khoản anfo được áp dụng cho mỗi khoản tín dụng hoặc ghi nợ. Cách phổ biến nhất mà các nhà phát triển API dùng là để lộ các khóa cơ sở dữ liệu, hoặc proxy trong các trường thực thể mà họ hiển thị. Tuy nhiên, ít nhất là đối với các API cho web, cách tiếp cận đó có một số nhược điểm so với phương pháp thay thế: liên kết web. Để tìm hiểu lý do, bạn hãy xem thêm bài viết Thiết kế API: Tại sao bạn nên sử dụng liên kết thay vì khóa để đại diện cho mối quan hệ trong API?

Tương tự, khi tạo URL cho API, một điều có thể gây nhầm lẫn nhưng có tác động, chính là việc nhận biết khi nào nên sử dụng URL với tên biến dễ đọc đối với con người và khi nào nên sử dụng URL dựa trên định danh số tĩnh (id). Ví dụ, một tài khoản ngân hàng có thể khó tham chiếu một cách tin cậy nếu một số nhận dạng không được sử dụng. Tất cả thông tin chi tiết về chủ sở hữu tài khoản đều có thể thay đổi (ví dụ: tên, địa chỉ, tình trạng hôn nhân), hoặc có thể không rõ ràng (ngày sinh, nơi sinh), hoặc cả hai trường hợp trên. Ngay cả khi có được con số nhận dạng đáng tin cậy cho chủ sở hữu, quyền sở hữu tài khoản vẫn có thể thay đổi. Mã nhận dạng số tĩnh là lựa chọn đáng tin cậy nhất. Để tìm hiểu sâu hơn về vấn đề này, hãy đọc bài viết Thiết kế API: Lựa chọn giữa tên và số định danh trong URL và đừng bỏ lỡ những chia sẻ cụ thể về sự cân bằng giữa khả năng đọc hiểu của con người và tính ổn định của hệ thống trong Phân loại URL sai trong Web API.

Các API được thiết kế để tiêu dùng, về cơ bản là các sản phẩm phần mềm dành cho các nhà phát triển. Hay nói cách khác, chúng có thể được tái sử dụng và cải tiến, giống như bất kỳ sản phẩm phần mềm nào khác. Tuy nhiên, việc lập và quản lý phiên bản cho của API mới có thể kéo theo một số điểm khác biệt, vì vậy hãy nhớ đọc kỹ Thiết kế API: Cách thức versioning nào phù hợp với bạn? và Những quan niệm sai lầm phổ biến về API Versioning.

Cuối cùng, các API có thể tác động đến cách một ứng dụng đơn trang (single-page) được định danh bằng chỉ mục bởi công cụ tìm kiếm. Nếu điều này nghe có vẻ phù hợp với nhu cầu của doanh nghiệp bạn, hãy xem bài viết Giải quyết vấn đề SEO với API của Google Cloud.

Làm được nhiều hơn với API

Giờ đây, bạn đang trên con đường tạo ra các API mạnh mẽ, thân thiện với người dùng và linh hoạt hơn, và vì các API tập trung vào mục đích tiêu dùng này là một phần để tạo nên điều kiện tái sử dụng, bạn cũng đang trên đường tạo ra vô số cách thức mới mẻ để xây dựng các ứng dụng phong phú nhanh chóng hơn. Để tìm hiểu thêm về cách API có thể thúc đẩy kết quả kinh doanh, hãy xem các bài viết về chủ đề liên quan đến API của Google Cloud từ Google Cloud Next ‘20: OnAir.

Nguồn: Google Cloud Blog