REST một cách hiệu quả để tạo nhiều mục trong một yêu cầu

Tôi đang làm việc trên một chương trình máy chủ khách hàng nhỏ để thu thập đơn đặt hàng. Tôi muốn làm điều này theo cách "REST (ful)".

Điều tôi muốn làm là:

Thu thập tất cả các đơn đặt hàng (sản phẩm và số lượng) và gửi đơn đặt hàng hoàn chỉnh đến máy chủ

Hiện tại, tôi thấy có hai tùy chọn để thực hiện việc này:

1. Gửi từng dòng đặt hàng đến máy chủ: POST qty và product_id

Tôi thực sự không muốn làm điều này vì tôi muốn giới hạn số lượng yêu cầu đến máy chủ nên tùy chọn 2:

2. Thu thập tất cả các dòng đặt hàng và gửi chúng đến máy chủ cùng một lúc.

Tôi nên thực hiện tùy chọn 2 như thế nào? Tôi có một vài ý tưởng là: Gói tất cả các dòng trong một đối tượng JSON và gửi nó đến máy chủ hoặc sử dụng một mảng để đăng các dòng.

Thực hiện tùy chọn 2 có phải là một ý tưởng hay hay không, và nếu có thì tôi nên làm như thế nào.

Thực hành tốt là gì?

Tôi tin rằng một cách đúng đắn khác để tiếp cận vấn đề này là tạo một tài nguyên khác đại diện cho bộ sưu tập tài nguyên của bạn. Ví dụ, hãy tưởng tượng rằng chúng ta có một điểm cuối giống như /api/sheep/{id}và chúng ta có thể ĐĂNG lên /api/sheepđể tạo tài nguyên cừu.

Bây giờ, nếu chúng tôi muốn hỗ trợ việc tạo số lượng lớn, chúng tôi nên xem xét một tài nguyên đàn mới tại /api/flock(hoặc /api/<your-resource>-collectionnếu bạn thiếu một cái tên có ý nghĩa hơn). Hãy nhớ rằng các tài nguyên không cần ánh xạ đến cơ sở dữ liệu hoặc mô hình ứng dụng của bạn . Đây là một quan niệm sai lầm phổ biến.

Tài nguyên là đại diện cấp cao hơn, không liên quan đến dữ liệu của bạn. Hoạt động trên một tài nguyên có thể có các tác dụng phụ đáng kể, như kích hoạt cảnh báo cho người dùng, cập nhật dữ liệu liên quan khác, bắt đầu một quy trình tồn tại lâu dài, v.v. Ví dụ: chúng tôi có thể ánh xạ hệ thống tệp hoặc thậm chí pslệnh unix dưới dạng API REST.

Tôi nghĩ rằng có thể an toàn khi cho rằng việc vận hành một tài nguyên cũng có thể có nghĩa là tạo ra một số thực thể khác như một tác dụng phụ.

Mặc dù các hoạt động hàng loạt (ví dụ: tạo hàng loạt) là điều cần thiết trong nhiều hệ thống, nhưng chúng không được giải quyết một cách chính thức theo kiểu kiến ​​trúc RESTful.

Tôi nhận thấy rằng ĐĂNG một bộ sưu tập như bạn đề xuất về cơ bản hoạt động, nhưng các vấn đề phát sinh khi bạn cần báo cáo lỗi theo yêu cầu như vậy. Những vấn đề như vậy sẽ tồi tệ hơn khi nhiều lỗi xảy ra vì các nguyên nhân khác nhau hoặc khi máy chủ không hỗ trợ giao dịch. Đề xuất của tôi cho bạn là nếu không có vấn đề gì về hiệu suất, chẳng hạn như khi nhà cung cấp dịch vụ ở trên mạng LAN (không phải WAN) hoặc dữ liệu tương đối nhỏ, thì việc gửi 100 yêu cầu POST đến máy chủ là điều đáng giá. Hãy đơn giản hóa, bắt đầu với các yêu cầu riêng biệt và nếu bạn gặp vấn đề về hiệu suất, hãy cố gắng tối ưu hóa.

Facebook giải thích cách thực hiện điều này: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Yêu cầu hàng loạt đơn giản

Lô API nhận vào một mảng các yêu cầu HTTP logic được biểu thị dưới dạng mảng JSON - mỗi yêu cầu có một phương thức (tương ứng với phương thức HTTP GET / PUT / POST / DELETE, v.v.), rel_url (phần của URL sau graph.facebook. com), mảng tiêu đề tùy chọn (tương ứng với tiêu đề HTTP) và một nội dung tùy chọn (cho các yêu cầu POST và PUT). Batch API trả về một mảng các phản hồi HTTP logic được biểu thị dưới dạng các mảng JSON - mỗi phản hồi có một mã trạng thái, một mảng tiêu đề tùy chọn và một nội dung tùy chọn (là một chuỗi được mã hóa JSON).

Ý tưởng của bạn có vẻ hợp lệ với tôi. Việc thực hiện là một vấn đề của sở thích của bạn. Bạn có thể sử dụng JSON hoặc chỉ các tham số cho mảng này (mảng "order_lines []") và làm

POST /orders

Vì bạn sẽ tạo ra nhiều tài nguyên hơn cùng một lúc trong một hành động (thứ tự và các dòng của nó), điều quan trọng là phải xác thực từng thứ và chỉ lưu chúng nếu tất cả chúng đều vượt qua xác thực, tức là. bạn nên làm điều đó trong một giao dịch.

Tôi đoán tốt hơn là gửi các yêu cầu riêng biệt trong một kết nối duy nhất . Tất nhiên, máy chủ web của bạn phải hỗ trợ nó

Tôi thực sự đã vật lộn với điều này gần đây và đây là những gì tôi đang hướng tới.

Nếu POST thêm nhiều tài nguyên thành công, hãy trả về 200 OK (Tôi đang xem xét là 201, nhưng cuối cùng người dùng không truy cập vào tài nguyên đã được tạo) cùng với một trang hiển thị tất cả các tài nguyên đã được thêm vào, ở dạng đã đọc -chỉ hoặc thời trang có thể chỉnh sửa. Ví dụ: người dùng có thể chọn và ĐĂNG nhiều hình ảnh lên thư viện bằng cách sử dụng biểu mẫu chỉ bao gồm một đầu vào tệp duy nhất. Nếu yêu cầu POST thành công toàn bộ, người dùng sẽ được cung cấp một tập hợp các biểu mẫu cho mỗi biểu diễn tài nguyên hình ảnh được tạo cho phép họ chỉ định thêm chi tiết về từng biểu mẫu (tên, mô tả, v.v.).

Trong trường hợp một hoặc nhiều tài nguyên không được tạo, trình xử lý POST sẽ hủy bỏ tất cả quá trình xử lý và nối từng thông báo lỗi riêng lẻ vào một mảng. Sau đó, Xung đột 419 được trả lại và người dùng được chuyển đến trang lỗi Xung đột 419 trình bày nội dung của mảng lỗi, cũng như cách quay lại biểu mẫu đã được gửi.

Bạn sẽ không muốn gửi tiêu đề HTTP cho 100 dòng đặt hàng. Bạn không muốn tạo thêm bất kỳ yêu cầu nào hơn mức cần thiết.

Gửi toàn bộ đơn đặt hàng trong một đối tượng JSON đến máy chủ, tới: máy chủ / đơn hàng hoặc máy chủ / đơn hàng / mới. Trả lại thứ gì đó trỏ đến: server / order / order_id

Cũng nên cân nhắc sử dụng CREATE PUT thay vì POST