Hệ thống API là gì?
API là viết tắt của chữ Application Programming Interface, dịch thuần Việt là “Giao diện lập trình ứng dụng”. Hiểu một cách sâu sắc hơn thì đó là những chuẩn kết nối, giao tiếp nhằm lấy thông tin hay dịch vụ do một bên cung cấp cho một hoặc một số bên khác sử dụng, có thể trừu tượng hoá bằng hình sau:
Tác dụng của API?
- Ứng dụng khả năng hiện thực cấu trúc micro-service trong phát triển phần mềm (chia nhỏ các chức năng thành các module nhỏ)
- Cung cấp back-end side cho webapp, mobile apps
- Sử dụng các tiện ích dịch vụ từ bên thứ 3 (3rd party service) như xác thực và lấy thông tin người dùng thông qua Facebook, Google, Stripe, etc. Đây là tác dụng phổ biến và dễ thấy nhất. Ngoài các dịch vụ về xác thực, mạng xã hội, API còn mang tới sự cung cấp dịch vụ thanh toán online, chỉnh sửa hình ảnh, gửi tin nhắn sms, chữ kí điện tử, upload/download files, etc.
- Cung cấp dịch vụ ra bên ngoài (đứng vai trò là 3rd party service)
-
Tham gia cộng đồng lập trình Web lớn nhất Việt Nam: Vietnamwebsummit.com
Mô thức hoạt động của API
Với bản chất là một giao diện, các thông tin về cách sử dụng API cần được công khai với người dùng, ít nhất là với các nhà lập trình của bên đối tác. Tất cả phương thức tiếp nhận, máy chủ và dữ liệu trả về đều do một tổ chức cụ thể nào đó cung cấp (API provider).
API provider sẽ chịu trách nhiệm vận hành máy chủ của họ và mở các cổng giao tiếp phù hợp cho người dùng sử dụng. Mọi vấn đề về dữ liệu lỗi, quá tải, sai ý nghĩa của cổng giao tiếp so với dữ liệu trả về đều do bên API provider chịu trách nhiệm.
Chính vì thế, khi sử dụng API, chúng ta gần như phải phó mặc chất lượng cho nhà cung cấp vì bản thân chúng ta không quyết định được gì cả. Chúng ta chỉ thấy và chỉ có khả năng làm những gì mà họ cho phép và cung cấp (dù cái họ cung cấp là dữ liệu sai, chậm, không rõ ràng :D)
Tiếp theo chúng ta sẽ đi tới các kinh nghiệm quan trọng về API của bản thân người viết và từ góp nhặt thông tin.
Các lưu ý trong việc sử dụng API
- Đôi khi những gì API provider cung cấp là không khả thi cho yêu cầu của khách hàng/quản lý dự án, người phát triển phần mềm cần dùng các thông tin và ví dụ cụ thể để chứng minh điều đó và đề xuất các giải pháp tốt nhất có thể. Đừng đâm đầu quá sâu vào vấn đề nằm ngoài phạm vi giải quyết của mình.
- Một số nhà cung cấp lớn vẫn có hệ thống documentation vô cùng tệ hại làm cho việc hiện thực API integration của nhà phát triển là một cuộc thử sai dài, bạn cần chấp nhận vấn đề này ^_^. Tuy nhiên, nên tận dụng tối đa tiện ích hỗ trợ của họ (nếu có) bằng cách hỏi thẳng những thắc mắc.
- Nếu nhà phát triển sản phẩm dùng một thư viện mã nguồn mở để đẩy nhanh tốc độ tích hợp API, việc có lỗi hay các warning khó chịu là bình thường vì không ai có trách nhiệm đảm bảo điều đó không xảy ra với bạn. Vì thế, “có qua có lại”, nếu bạn có thể giải quyết một vấn đề nào đó, hãy đóng góp mã nguồn của bạn để khắc phục cho cả những người khác (chẳng phải bạn cũng đang dùng lòng tốt của người khác hay sao?!).
Các lưu ý trong việc phát triển API
- API versioning là việc chia phiên bản cho hệ thống API mà bạn cung cấp. Tại sao phải chia phiên bản API? Vì bạn muốn giữ nguyên mọi thứ liên quan đến hệ thống API cũ và cung cấp một hệ thống API hoàn toàn mới, không ảnh hưởng tới những tích hợp API cũ. Ví dụ: google/v1/user/lehoang1417sẽ trả về handsome nhưng google/v2/user/lehoang1417 sẽ trả về awesome ?
- Tuỳ sự độc lập trong thiết kế hệ thống mà nguy cơ thay đổi mới sẽ ảnh hưởng tới các phiên bản cũ nhiều hay ít. Nhưng trong trường hợp nào thì bạn cũng cần ý thức và đề phòng vấn đề này.
- Đối với mobile apps, khi đã release thì ta không thể thay đổi API version mà nó gọi tới nếu như chúng ta chỉ quyết định phiên bản API trả về theo cái mà nó request lên. Vì thế cần thật cẩn thận trong các lần release.
- Tuy nhiên, có một cách có thể thay đổi mobile apps’ requests API version một cách chủ động bằng cách trong request của app phải có cả app_type và app_version. Chúng ta sẽ dựa vào đó quyết định version trả về mong muốn.
Chúc các bạn sử dụng và nghiên cứu API thành công ?
ITZone via hoangle