Providing the Best Shipping Rates Through APIs có gì mới?

• Bài viết nói về cách lấy báo giá vận chuyển tự động bằng API thay vì nhập tay.
• Tác giả dùng EasyShip để hỏi hệ thống giao hàng xem phí ship là bao nhiêu.
• Dữ liệu từ trang bán hàng được gửi lên máy chủ rồi mới chuyển tiếp sang EasyShip.
• Kết quả trả về là danh sách nhiều lựa chọn ship từ các đơn vị vận chuyển khác nhau.
• Mục tiêu tiếp theo là hiển thị lựa chọn tốt nhất cho người bán hoặc người mua.

Trong quá trình xây dựng một trang bán hàng, tác giả nhận ra một vấn đề rất thực tế: sản phẩm đã gần hoàn thiện, nhưng vẫn thiếu phần giao hàng. Nếu người dùng không biết phí ship là bao nhiêu thì họ chưa thể chốt đơn một cách tự tin. Thay vì tự tính phí vận chuyển bằng tay, tác giả chọn dùng một dịch vụ có sẵn là EasyShip. Cách làm này giúp tiết kiệm thời gian và giảm lỗi, vì hệ thống sẽ tự hỏi mức giá từ nhiều đơn vị vận chuyển rồi trả kết quả về cho ứng dụng. Nói đơn giản, bài viết đang kể lại cách một ứng dụng bán hàng “gọi điện” cho dịch vụ giao hàng để xin báo giá. Trong thế giới công nghệ, cách “gọi điện” đó thường được thực hiện qua API. API là viết tắt của “Application Programming Interface”, nhưng hiểu dễ hơn thì nó giống như một người trung gian. Bạn đưa yêu cầu cho người trung gian, rồi họ mang yêu cầu đó sang hệ thống khác và đem kết quả quay lại.

Khách gọi món với phục vụ, phục vụ chuyển yêu cầu vào bếp, rồi mang món ăn ra bàn. Ở đây, API đóng vai trò như người phục vụ đó. Điểm quan trọng của bài viết không nằm ở việc viết code phức tạp, mà là cách tổ chức luồng dữ liệu cho đúng. Trước hết, giao diện người dùng thu thập thông tin như địa chỉ gửi hàng, địa chỉ nhận hàng, kích thước kiện hàng và giá trị món hàng. Sau đó, dữ liệu này được đóng gói thành một “payload”. Có thể hiểu payload là một gói thông tin được xếp theo đúng định dạng mà hệ thống bên kia yêu cầu. Nếu đóng gói sai, API có thể không hiểu hoặc từ chối xử lý. Vì vậy, phần chuẩn bị dữ liệu là bước rất quan trọng, dù người dùng cuối thường không nhìn thấy nó. Tác giả dùng `fetch()` để gửi dữ liệu từ trình duyệt lên máy chủ. Với người không chuyên, `fetch()` chỉ là cách ứng dụng gửi một yêu cầu qua mạng và chờ phản hồi.

Lý do không gửi thẳng từ trình duyệt tới EasyShip là vì tác giả muốn giữ dữ liệu nhạy cảm an toàn hơn. Thay vì để địa chỉ hoặc thông tin vận chuyển xuất hiện trực tiếp trên đường truyền từ giao diện ra ngoài, ứng dụng sẽ gửi trước cho máy chủ nội bộ rồi máy chủ mới làm việc với EasyShip. Ở phía máy chủ, ứng dụng dùng Express.js để tạo một đường dẫn nhận dữ liệu, gọi là route. Bạn có thể hiểu route như một “cửa nhận yêu cầu” trong hệ thống. Tác giả chọn dùng POST thay vì GET. Điều này nghe có vẻ kỹ thuật, nhưng lý do rất dễ hiểu: POST phù hợp hơn khi cần gửi dữ liệu riêng tư hoặc dữ liệu nhiều trường, còn GET thường làm lộ thông tin ra trên địa chỉ URL. Khi máy chủ nhận được dữ liệu, nó tách từng phần ra để xử lý. Việc tách này được gọi là “destructuring”, nhưng bạn chỉ cần hiểu là máy chủ lấy riêng địa chỉ gửi, địa chỉ nhận và thông tin kiện hàng để dùng ở bước tiếp theo.

Ứng dụng hỏi EasyShip xem với thông tin kiện hàng này thì có những mức phí vận chuyển nào. Cấu hình trong yêu cầu này khá chi tiết nhưng ý chính thì rất dễ hiểu:

• Địa chỉ gửi và nhận được truyền vào.
• Hàng hóa được khai báo là kiểu giao thông thường trong nước.
• Đơn vị đo cân nặng dùng pound, còn kích thước dùng inch.
• Dữ liệu về thùng hàng, trọng lượng và món hàng bên trong cũng được gửi đi.
• Phần thuế và phí nhập khẩu được tắt vì tác giả đang làm cho đơn nội địa ở Mỹ.

Tác giả cũng đặt một số giá trị mặc định để hệ thống không bị thiếu dữ liệu. Ví dụ, nếu chưa có giá món hàng thì hệ thống vẫn lấy một con số tối thiểu để tiếp tục xử lý. Khi EasyShip trả kết quả, máy chủ ghi log lại để tiện kiểm tra lỗi rồi gửi dữ liệu về lại giao diện. Kết quả này sau đó sẽ được dùng để hiển thị các lựa chọn vận chuyển cho người dùng. Có một điểm rất đáng chú ý là API không trả về “một giá duy nhất”. Thay vào đó, nó thường trả về nhiều lựa chọn từ các đơn vị giao hàng khác nhau, để ứng dụng có thể chọn phương án phù hợp nhất.

• `Rates`: danh sách các mức phí vận chuyển.

- `Meta`: thông tin bổ sung về yêu cầu. Phần `rates` là thứ hữu ích nhất với người dùng vì nó cho thấy nhiều lựa chọn ship khác nhau. Từ đó, ứng dụng có thể sắp xếp theo giá rẻ, thời gian giao hàng nhanh, hoặc khoảng cách vận chuyển trung bình. Nếu nói theo cách đời thường, đây giống như việc bạn nhập điểm đi và điểm đến, rồi hệ thống tự gọi nhiều hãng giao hàng để hỏi giá. Thay vì bạn phải mở từng trang web để kiểm tra, hệ thống làm hộ bạn trong vài giây. Bài viết cũng nhấn mạnh vai trò của việc xử lý lỗi. Khi kết nối với API bên ngoài, chuyện lỗi mạng, sai định dạng dữ liệu, hoặc thiếu thông tin là rất bình thường. Tác giả dùng khối `catch` để bắt lỗi và in ra chi tiết lỗi ở dạng dễ đọc hơn. Điều này giúp lập trình viên biết vấn đề nằm ở đâu thay vì thấy ứng dụng “đứng im” mà không hiểu lý do.

• API giúp ứng dụng kết nối với dịch vụ bên ngoài mà không cần tự xây toàn bộ từ đầu.
• Dữ liệu phải được gửi đúng định dạng thì dịch vụ mới hiểu.
• Nên để máy chủ xử lý các yêu cầu quan trọng thay vì gửi trực tiếp từ giao diện.
• Có nhiều lựa chọn ship giúp người dùng chọn theo nhu cầu, không bị ép vào một phương án.
• Xử lý lỗi là phần bắt buộc nếu muốn ứng dụng chạy ổn định.

Bài viết thực chất là một lát cắt rất phổ biến trong thương mại điện tử hiện đại. Khi bạn thấy ở một trang bán hàng có dòng “tính phí vận chuyển”, phía sau thường là cả một chuỗi làm việc giữa giao diện, máy chủ và dịch vụ giao hàng. Điều đáng giá của bài này là cách tác giả đi từ vấn đề thực tế đến giải pháp rõ ràng. Không phải là “dùng công nghệ cho hay”, mà là dùng đúng công cụ để làm cho việc tính phí ship bớt thủ công hơn.

Nếu có dịch vụ đã làm tốt phần vận chuyển, hãy tận dụng nó. Việc tự xây toàn bộ hệ thống từ đầu thường tốn thời gian hơn nhiều, trong khi một API tốt có thể giúp bạn đi nhanh hơn.

Ứng dụng bán hàng hỏi dịch vụ ship qua API, rồi đưa các mức phí về cho người dùng xem. Phần khó nằm ở chỗ dữ liệu phải đúng chuẩn và luồng xử lý phải an toàn, nhưng ý tưởng tổng thể thì khá đơn giản.

Insight giúp bạn nắm ý chính của một bài dài mà không phải đọc hết từng chi tiết kỹ thuật. Điều này rất hữu ích khi bạn muốn hiểu nhanh một xu hướng sản phẩm, công nghệ, kinh doanh hoặc thiết kế mà không có nhiều thời gian. Điểm mạnh của các bản tóm tắt là chúng lọc bớt phần nhiễu như cú pháp code, ví dụ rườm rà hay giải thích lặp lại. Bạn vẫn hiểu được vấn đề chính, cách giải quyết và kết quả cuối cùng, nhưng với tốc độ nhanh hơn nhiều.

Ngắn gọn, rõ ý, ít thuật ngữ khó. Khi gặp khái niệm mới, Insight thường diễn giải theo ngôn ngữ đời thường để bạn không bị “ngợp” bởi từ chuyên môn. Ngoài ra, đọc tóm tắt giúp bạn dễ quyết định có nên tìm hiểu sâu hơn hay không. Chỉ cần vài phút, bạn đã biết bài đó có đáng đọc tiếp, áp dụng được gì, hay chỉ là nội dung kỹ thuật quá hẹp với nhu cầu của mình.