Hợp nhất và chia tách tài nguyên

Question

Tôi có dịch vụ REST phục vụ chức năng Hóa đơn, ví dụ tôi có thể tạo, cập nhật và xóa hóa đơn qua dịch vụ REST. Tuy nhiên, bây giờ tôi cần có chức năng chia hóa đơn thành nhiều hóa đơn mới, tức là phương thức cần tạo x hoá đơn dựa trên một hóa đơn, sau đó xóa hóa đơn gốc trong một giao dịch.

Tôi cũng cần phương thức hợp nhất ngược lại, tức là nhiều hóa đơn được hợp nhất thành một.

Làm cách nào để tạo kiến ​​trúc sư như vậy theo cách RESTful?

Answer 1

Chúng tôi gặp sự cố tương tự khi chúng tôi muốn hợp nhất 2 tài nguyên. Sau một cuộc tranh luận dài, chúng tôi quyết định rằng một người tiêu dùng sẽ POST một nguồn yêu cầu hợp nhất có chứa 2 tài nguyên được sáp nhập. Sau đó, sau khi nhìn vào nó, chúng tôi quyết định rằng không cần cả nguồn hoàn chỉnh và tài nguyên đích và thay vào đó POST chỉ là số nhận dạng duy nhất là đủ. Chúng tôi đã không đưa ra yêu cầu hợp nhất chỉ với 2 ID đến trong cơ thể. Nó được dễ dàng hơn để đại diện trong một URL vì vậy đó là những gì chúng tôi đã làm. Phản hồi từ POST của yêu cầu hợp nhất là tài nguyên đã hợp nhất.

Tôi đoán tôi không phải là một guru REST đủ để cho bạn biết đây là một chiến lược tốt hay không, nhưng đối với chúng tôi nó là một giải pháp đơn giản vì vậy chúng tôi đã đi với nó.

Answer 2

Khi bạn nói rằng muốn triển khai chức năng này trong "một giao dịch", giả sử bạn đã xác định rằng bạn nên kết hợp tạo các hóa đơn mới và xóa hóa đơn cũ thành một cuộc gọi API; đó là cách tiếp cận chính xác. Với các dịch vụ web bạn muốn giảm bớt trò chuyện và có thể một số logic nghiệp vụ về cách chức năng này sẽ tạo ra các hóa đơn mới và xóa hóa đơn cũ. Vì vậy, tôi giả sử khi bạn hỏi cách kiến ​​trúc sư này theo cách RESTful, bạn đang tự hỏi động từ HTTP nào sử dụng (tức là GET, POST, PUT hoặc DELETE) cho phương thức API mới này. Thường lập bản đồ những động từ các hoạt động kiểu CRUD theo cách sau đây:

• Tạo -> POST
• đọc -> GET
• Update -> PUT
• Xóa -> DELETE

Vì vậy, động từ nào sẽ sử dụng khi hàm của bạn tạo và xóa các bản ghi. Một nguyên tắc chung với REST API là nếu không có ánh xạ rõ ràng với CRUD thì sử dụng POST nếu có sự thay đổi trạng thái máy chủ và một GET nếu bạn chỉ trả về thông tin không thay đổi trạng thái máy chủ. Vì vậy, trong trường hợp này tôi sẽ đi với một POST.

Nếu bạn đang tìm kiếm hướng dẫn bổ sung về kiến ​​trúc này, hãy cụ thể hơn về những gì bạn đang tìm kiếm và tôi sẽ cố gắng trợ giúp.

Answer 3

tôi sẽ làm một cái gì đó như thế nào,

POST /InvoiceSplitter?sourceInvoiceId=99 

và

POST /InvoiceMerger?sourceInvoiceIds=101,87,23,45