RESTful API cho website bán hàng

Xin chào mọi người,

Mình đang tìm hiểu và làm một website bán hàng cơ bản (theo kiến trúc Microservices - là đồ án nên làm thử cho vui). Các chức năng như:

Với người dùng: Xem sản phẩm, tạo giỏ hàng, đặt hàng, kiểm tra đơn hàng đã đặt,…
Với admin: Thêm, sửa, xóa danh mục, sản phẩm, duyệt đơn hàng, theo dõi đơn hàng, tạo báo cáo,…

Theo dự định thì phần server-side dùng Spring Boot và Spring Cloud để tạo API, client-side dùng AngularJS để tiêu thụ API.

Công nghệ nào dùng ở đây có lẽ không quan trọng mấy, vấn đề là mình chưa có kinh nghiệm với web dạng này bao giờ nên phần thiết kế API cảm thấy hơi bức bối. Mong ae có kinh nghiệm tham gia góp ý, hoặc có nguồn tham khảo thì cùng chia sẻ :))))))

Nhớ cho mình: API nó chỉ là cái tên thôi.
Mô hình chung của server - client là gì: Client gửi request, server nhận và xử lý request, sau đó server trả response về cho client.
Giờ bạn làm một route để trả về 1 html hoàn chỉnh cho client thì nó chẳng khác gì bạn làm 1 route để trả về json cho client cả.
Nói chung Spring Boot với Spring Cloud của bạn sẽ có cac endpoint, trong đó có những endpoint dùng để trả về html cho client (khi user gõ link rồi enter, hoặc khi người ta click vào hyperlink để change document location), hoặc có các endpoint làm theo kiểu RestAPI, đơn giản là trả về json (thay vì trả về html) kết quả cho client, đồng thời đảm bảo không tích lũy trạng thái của server (ko tính cho DB).

3 Likes

Lời khuyên:

  1. Phân nhóm chức năng. Có thể phân theo mục đích sử dụng hoặc phân theo object
  2. Sau khi phân nhóm phải đảm bảo các nhóm không bị phụ thuộc vào nhau
  3. Focus vào hoàn thiện từng nhóm một. Không ôm đồm 1 lúc vì scope lớn, làm dàn trải dễ nản mà ko bao h xong
  4. Rest APi thì làm server side trước, test ổn với các tool (soapui, restful plugin…) rồi mới làm client (xài mấy cái template trên mạng cho lẹ, sau custom lại)
  5. Đọc các tài liệu hướng dẫn naming cho rest (tự google vì nó rất phổ biến, gợi ý vài từ khóa như “restful best practices”
  6. Nguyên tắc khi phát triển 1 mình là release từng phần để giữ động lực :slight_smile:
3 Likes

Cảm ơn bạn, mình biết API là gì mà :))

Quan trọng là mình chưa rõ nghiệp vụ của bài toán kiểu này, và sẽ cần các API như nào và thao tác với tài nguyên gì. Mình cần một mẫu để tham khảo ấy.

Cảm ơn bạn,

  1. Mình định tham khảo được một list API nào đấy rồi thiết kế phần model (thực thể) cho dễ, vì chưa có kinh nghiệm gì. Xây nhà xong vẽ bản thiết kế thì dễ hơn rồi :))) Nhưng chắc lại phải quay lại phân tích model trước, sau đó gom nhóm và thiết kế API.

Mình có xem qua API của Opencart (http://api.opencart-api.com/demo/shopping-cart/) - một opensource shopping cart, nhưng bài toán của họ lớn nên rất khó để tổng hợp lại những thứ mình cần.

vài ví dụ về mindset khi thiết kế api:

  1. App có cần quản lý user?
    -> Có: /api/user/*
    -> Không/hoặc tạm thời không cần: qua chức năng khác
  2. App này quản lý 1 loại sản phẩm hay nhiều loại (catalog)?
    -> Có: /api/catalog/*
    -> Không/hoặc tạm thời không cần: qua chức năng khác
    .
    .
    …Đại khái là xác định trước cái nào cần/không cần/tạm thời chưa cần để xác định mức độ ưu tiên rồi sau đó focus vào cái cần (nhưng dễ) để làm trước (giữ động lực) rồi làm tiếp mấy cái khó.

p/s: đối việc thiết kế phần mềm nếu làm 1 mình thì qua các bước như này sẽ không bị quá tải:
phân tích nghiệp vụ --> định nghĩa DB --> thiết kế service --> thiết kế UI

1 Like

Tham khảo mô hình của Tiki

3 Likes

Cảm ơn bạn,

Mấy cái DDD thì hơi trìu tượng, nhưng chắc cũng cố gắng áp dụng vài cái như repository, service,… cho logic rõ ràng

Còn event driven chắc sẽ cố nhét vài case.

Mấy cái này cao siêu quá :(((

Mình sẽ bám theo quy trình của bạn, có gì lại lên đây hỏi :smile:

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?