Gần đến ngày cuối cùng của tuần nghỉ lễ dài, tôi miên man nghĩ đến vấn đề về estimate , dự định sáng nay viết một bài về đề tài này. Nhưng chợt nhớ đến phần thiết kế cơ bản còn thiếu – thiết kế API.
API là một mảng kiến thức rộng lớn và rất thú vị. Hầu hết các dự án dính đến client – server đều có mặt API, các phương thức cơ bản sử dụng chủ yếu trong API là POST, GET, DELETE – sự khác biệt giữa các phương thức ( POST, GET ) như thế nào , ae hỏi thánh Google nhé, bởi bài viết này chỉ tập trung đến chia sẻ thiết kế API mà thôi.
Để viết được thiết kế API , thì người thiết kế phải hiểu được mục đích sử dụng API vào làm việc gì , đòi hỏi tính security như thế nào?
Sau khi đã clear ngọn ngành rồi mới bắt tay vào thiết kế. Ví dụ, dự án vừa rồi mình đã triển khai, bài toán đưa ra phải thiết kế 2 API, một là API check account đăng nhập từ một hệ thống khác, và một API ghi log thao tác của người dùng. Do hệ thống được build trong nội bộ công ty sử dụng, nên tính security đòi hỏi ở mức trung bình – cần sử dụng một khóa token là okie. Tuy nhiên khi comfirm tài liệu với khách hàng, nội dung chỉ cần ghi log check thao tác user login /logout từ hệ thống khác thôi. Như vậy với yêu cầu này, mình có thể thiết kế một API là đủ. Bài học ở đây là có thể khách hàng thiếu sót trong việc update tài liệu, tuy nhiên mình luôn cần chủ động cập nhật kế hoạch, cách hiểu và phương thức triển khai . Việc chủ động này, thể hiện qua việc chourei hàng ngày, hoặc email báo cáo cuối ngày cho người phụ trách , đảm bảo luồng thông tin luôn được cập nhật, không bị ứ đọng ở một nút thắt nào. Ấy cũng là cách tư duy , hay phong cách làm việc của người nhật, dù cho bất kỳ tình huống nào – tồi tệ đến đâu chăng nữa, thông tin luôn phải chủ động .
Quay lại vấn đề trên, khi clear được input đầu vào, tiếp đến phải xác định được các param cần sử dụng là như thế nào, số lượng ra sao. Ví dụ làm một API check verify tài khoản thì param cần có là userID / Password là đủ, tuy nhiên một số hệ thống bảo mật cần thêm thông tin IP từ phía client truyền lên nữa…Khi request đến một link url bằng một phương thức chỉ định trước, thì server sẽ trả về kết quả đúng hoặc sai, nếu đúng thì là mã code là như thế nào, message ra sao, bala bala… mọi định nghĩa được mô tả kỹ trong bản thiết kế API.
Cụ thể một API sẽ được thiết kế như sau
API là một mảng kiến thức rộng lớn và rất thú vị. Hầu hết các dự án dính đến client – server đều có mặt API, các phương thức cơ bản sử dụng chủ yếu trong API là POST, GET, DELETE – sự khác biệt giữa các phương thức ( POST, GET ) như thế nào , ae hỏi thánh Google nhé, bởi bài viết này chỉ tập trung đến chia sẻ thiết kế API mà thôi.
Để viết được thiết kế API , thì người thiết kế phải hiểu được mục đích sử dụng API vào làm việc gì , đòi hỏi tính security như thế nào?
Sau khi đã clear ngọn ngành rồi mới bắt tay vào thiết kế. Ví dụ, dự án vừa rồi mình đã triển khai, bài toán đưa ra phải thiết kế 2 API, một là API check account đăng nhập từ một hệ thống khác, và một API ghi log thao tác của người dùng. Do hệ thống được build trong nội bộ công ty sử dụng, nên tính security đòi hỏi ở mức trung bình – cần sử dụng một khóa token là okie. Tuy nhiên khi comfirm tài liệu với khách hàng, nội dung chỉ cần ghi log check thao tác user login /logout từ hệ thống khác thôi. Như vậy với yêu cầu này, mình có thể thiết kế một API là đủ. Bài học ở đây là có thể khách hàng thiếu sót trong việc update tài liệu, tuy nhiên mình luôn cần chủ động cập nhật kế hoạch, cách hiểu và phương thức triển khai . Việc chủ động này, thể hiện qua việc chourei hàng ngày, hoặc email báo cáo cuối ngày cho người phụ trách , đảm bảo luồng thông tin luôn được cập nhật, không bị ứ đọng ở một nút thắt nào. Ấy cũng là cách tư duy , hay phong cách làm việc của người nhật, dù cho bất kỳ tình huống nào – tồi tệ đến đâu chăng nữa, thông tin luôn phải chủ động .
Quay lại vấn đề trên, khi clear được input đầu vào, tiếp đến phải xác định được các param cần sử dụng là như thế nào, số lượng ra sao. Ví dụ làm một API check verify tài khoản thì param cần có là userID / Password là đủ, tuy nhiên một số hệ thống bảo mật cần thêm thông tin IP từ phía client truyền lên nữa…Khi request đến một link url bằng một phương thức chỉ định trước, thì server sẽ trả về kết quả đúng hoặc sai, nếu đúng thì là mã code là như thế nào, message ra sao, bala bala… mọi định nghĩa được mô tả kỹ trong bản thiết kế API.
Cụ thể một API sẽ được thiết kế như sau
Tóm lại thiết kế API tùy vào từng hệ thống sẽ có độ phức tạp khác nhau, để viết được thiết kế API là không khó, cái khó ở đây là có nắm được thông tin input rõ ràng , hiểu được mục đích sử dụng API trong hệ thống hay không mà thôi.
Mọi người có thể download , sử dụng template API bên link bên dưới.
【xxxxxxxxxxxxシステム】API一覧
Mọi người có thể download , sử dụng template API bên link bên dưới.
【xxxxxxxxxxxxシステム】API一覧
No comments:
Post a Comment