API RESTful: Tôi nên viết mã cho luồng công việc của mình ở đâu?

Question

Tôi đang phát triển API RESTful. Đây là API đầu tiên của tôi, nhưng cũng là dự án mã hóa thực sự lớn đầu tiên của tôi. Như vậy, tôi vẫn đang học hỏi rất nhiều về kiến ​​trúc, vv

Hiện nay, tôi đã thiết lập api của tôi trong các lớp sau:

• HTTP lớp
• Resource lớp
• Domain Model/Kinh doanh logic lớp
• Data Access/Repository lớp
• dai dẳng lưu trữ/DB lớp

Vấn đề tôi đã gặp phải vào lúc này là nơi tôi cần phải đặt đối tượng/người quản lý luồng công việc? Theo quy trình công việc, tôi có nghĩa là mã đánh giá bước tiếp theo là yêu cầu của người dùng cuối. Ví dụ: quy trình làm việc thương mại điện tử. Người dùng thêm mục vào giỏ, sau đó kiểm tra, sau đó điền vào các chi tiết cá nhân, sau đó trả tiền. Quy trình làm việc sẽ chịu trách nhiệm quyết định các bước tiếp theo, nhưng cũng không cho phép các bước nào. Ví dụ: người dùng không thể gây ra lỗi trong API bằng cách cố gắng thanh toán trước khi họ nhập chi tiết cá nhân (có thể họ gọi lại URI để thanh toán và cố gắng bỏ qua một bước). Quy trình làm việc sẽ kiểm tra để thấy rằng tất cả các bước trước đã được hoàn thành, nếu không, sẽ không cho phép thanh toán.

Hiện tại, luồng công việc của tôi nằm trong Lớp tài nguyên. Tôi đang sử dụng các liên kết hypermedia để trình bày quy trình làm việc cho người dùng, ví dụ: cung cấp liên kết 'bước tiếp theo'. Vấn đề tôi có với điều này là lớp tài nguyên là lớp cấp cao nhất và phù hợp hơn với bản trình bày. Tôi cảm thấy cần phải biết quá nhiều về mô hình miền cơ bản để đánh giá hiệu quả luồng công việc tức là cần biết rằng phải kiểm tra thực thể personal_detail trước khi cho phép thanh toán.

Điều này giờ đây khiến tôi nghĩ rằng luồng công việc thuộc về mô hình miền. Điều này có ý nghĩa hơn rất nhiều, vì luồng công việc thực sự là một phần của logic nghiệp vụ và do đó tôi nghĩ là tốt nhất được đặt trong lớp miền. Sau khi tất cả, thay thế lớp tài nguyên với một cái gì đó khác, và bạn vẫn sẽ cần các quy trình công việc cơ bản.

Nhưng bây giờ vấn đề là luồng công việc cần kiến ​​thức về một số đối tượng miền để hoàn thành logic của họ. Nó bây giờ cảm thấy đúng rằng nó có thể đi trong lớp riêng của mình? Giữa tài nguyên và lớp miền?

• HTTP lớp
• Resource lớp
• Workflow lớp
• Domain Model/Business Logic lớp
• Data Access/Repository lớp
• dai dẳng lưu trữ/DB lớp

Im chỉ tự hỏi nếu bất cứ ai có bất kỳ quan điểm hoặc suy nghĩ khác xung quanh điều này? Như tôi đã nói, tôi không có kinh nghiệm ứng dụng trong quá khứ để biết nơi công việc nên được đặt. Im thực sự chỉ cần học tập này lần đầu tiên vì vậy muốn chắc chắn rằng tôi đang đi về nó đúng cách.

Liên kết tới các bài viết hoặc blog bao gồm điều này sẽ được đánh giá cao. Tình yêu đọc lên trên các triển khai khác nhau.

EDIT

Để làm rõ, tôi phát hành mà HATEOAS cho phép khách hàng để điều hướng thông qua các 'công việc', nhưng phải có cái gì đó trong API của tôi mà biết những gì liên kết để hiển thị tức là nó thực sự là xác định công việc đó là được phép. Nó trình bày các liên kết luồng công việc có liên quan trong tài nguyên, nhưng bổ sung nó xác nhận các yêu cầu được đồng bộ với luồng công việc. Trong khi tôi đồng ý rằng một khách hàng có thể sẽ chỉ theo các liên kết được cung cấp trong tài nguyên, sự nguy hiểm (và vẻ đẹp) của phần còn lại, đó là URI của nó được điều khiển, vì vậy không có gì ngăn cản một khách hàng tinh nghịch cố gắng 'bỏ qua' các bước trong luồng công việc thực hiện dự đoán có giáo dục tại URI. API cần phát hiện ra điều này và trả về phản hồi 302.

Answer 1

Câu trả lời cho câu hỏi này đã đưa tôi một chút công bằng về nghiên cứu, nhưng về cơ bản phần 'quy trình làm việc' không liên quan gì đến REST và nhiều hơn nữa để làm với lớp ứng dụng.

Hệ thống của tôi đã có logic ứng dụng và API REST quá chặt chẽ. Tôi đã giải quyết vấn đề của mình bằng cách tái cấu trúc để giảm khớp nối và hiện tại luồng công việc nằm trong ngữ cảnh của ứng dụng

Answer 2

REST khuyến khích bạn tạo từ vựng danh từ (người dùng, sản phẩm, giỏ hàng) chống lại một tập hợp các động từ (GET, POST, PUT, DELETE). Nếu bạn tuân thủ quy tắc này, thì trong ví dụ của bạn, quy trình làm việc thực sự được xác định bằng tập hợp các tương tác mà người dùng có với trang web của bạn. Đó là cách người dùng sử dụng ứng dụng của bạn, ứng dụng này thực sự được xác định bởi giao diện người dùng. Các dịch vụ REST của bạn nên phản ứng thích hợp với các yêu cầu trạng thái không hợp lệ, chẳng hạn như cố gắng thanh toán bằng một giỏ hàng trống, nhưng giao diện người dùng cũng có thể ngăn các yêu cầu đó bằng cách sử dụng tập lệnh, đó là một đặc tính tùy chọn của REST.

Ví dụ: Giao diện người dùng hiển thị sản phẩm cho người dùng cũng có thể hiển thị liên kết cho phép người dùng thêm sản phẩm đó vào giỏ hàng của họ (POST shoppingcart/{productId}). Máy chủ thực sự không nên quan tâm đến cách người dùng truy cập vào POST đó, chỉ rằng nó nên thêm sản phẩm đó vào giỏ hàng của người dùng và trả về đại diện cập nhật của giỏ hàng cho người dùng. Giao diện người dùng sau đó có thể sử dụng javascript để xác định có hay không hiển thị một liên kết để thanh toán chỉ khi giỏ hàng có một hoặc nhiều mục. Vì vậy, có vẻ như quy trình làm việc của bạn sống bên ngoài dịch vụ REST và được định nghĩa bởi điều hướng trong các trang của bạn, tương tác với các dịch vụ REST của bạn khi người dùng yêu cầu mọi thứ. Chắc chắn bạn có thể có quy trình làm việc nội bộ phải xuất hiện trong ứng dụng của bạn dựa trên các cài đặt trạng thái của người dùng. Nhưng những gì bạn dường như mô tả là tương tác của người dùng trong trang web và trong khi đó thực sự là luồng công việc, có vẻ như giao diện người dùng của bạn được định nghĩa tốt hơn so với thành phần/lớp dành riêng cho máy chủ.

Answer 3

Bạn có thể muốn định hướng lại kiến ​​trúc của mình dọc theo các dòng DDD (Domain Driven Design) và có thể sử dụng MSA, theo cách đó, bạn có thể chuyển từ luồng công việc được dàn dựng sang EDA và vũ đạo các quy trình vi mô.

Answer 4

Bạn chạm vào luồng công việc (còn gọi là logic nghiệp vụ) của một API. Về mặt kỹ thuật, đây là một mối quan tâm riêng biệt từ phần API là giao diện. Chắc chắn, như bạn đề cập, HATEOAS cho phép bạn đề xuất một số hành động hợp lệ, nhưng bạn nên cẩn thận để duy trì statelessness.

Trong ứng dụng REST, không được trạng thái phiên được lưu trữ ở phía máy chủ. Thay vào đó, nó phải được xử lý hoàn toàn bởi khách hàng.

Vì vậy, nếu có trạng thái phiên trên máy chủ, nó không phải là REST.

Ví dụ về giỏ hàng của bạn, bạn có thể lưu trạng thái trong một lớp bộ nhớ đệm riêng biệt như Redis.Đối với quy trình công việc của bạn. Bạn sẽ không muốn đặt logic nghiệp vụ như tính toán giỏ hàng của họ hoặc tổng hóa đơn trong một mô hình miền. Điều đó sẽ được thêm vào lớp dịch vụ.

Bạn đã nói về những người dùng tinh nghịch đoán URL. Điều này luôn luôn là một mối quan tâm và cần được xử lý bởi sự an toàn của bạn. Nếu URL xóa người dùng là DELETE/user/3782 ... họ có thể dễ dàng đoán cách xóa tất cả người dùng. Nhưng bạn không nên chỉ dựa vào obfuscating các URL. Bạn nên có bảo mật thực và kiểm tra truy cập bên trong các điểm cuối của bạn kiểm tra xem mỗi yêu cầu có hợp lệ hay không.

Đây là giải pháp tương tự cho các lo ngại về giỏ hàng của bạn. Bạn cần cấp mã thông báo mua sắm và sử dụng thông tin đó để xác thực từng hành động, bất kể họ có biết đúng URL hay không. Không có phím tắt nào khi nói đến bảo mật.