Thiết kế REST API để sao chép tài nguyên

Question

Tôi đang viết một tài liệu YAML bằng cách sử dụng công cụ chuyển đổi để thiết kế một phương thức RESTful API để nhân bản một tài nguyên. Tôi có một vài lựa chọn và không biết cái nào là tốt nhất. Xin vui lòng ai đó có thể tư vấn cho?

Options:

1. từ bỏ trách nhiệm của nhân bản đối tượng tài nguyên cho người tiêu dùng (nơi người tiêu dùng gán giá trị cho các thuộc tính trên một đối tượng mới và sau đó tạo ra một đối tượng mới), quá trình này sẽ cần phải bao gồm hai yêu cầu đối với API: một GET đối với tài nguyên cho đối tượng nguồn và sau đó là POST cho tài nguyên đó để tạo tài nguyên mới. Điều này giống như người tiêu dùng có quá nhiều trách nhiệm.
2. Sử dụng tiện ích mở rộng HTTP WebDAV cung cấp phương thức COPY (see here). Nó sẽ xuất hiện rằng đây là chính xác những gì tôi muốn cho nhân bản. Tuy nhiên, tôi muốn tuân thủ các phương pháp tiêu chuẩn càng nhiều càng tốt
3. Đăng lên/{resource}? ResourceIdToClone = {id} trong đó resourceIdToClone là tham số tùy chọn. Điều này sẽ xung đột với một đường dẫn API mà tôi đã có để tạo tài nguyên, nơi tôi thêm một lược đồ vào cơ thể POST. Điều đó có nghĩa là sử dụng POST tới/{resource}/để tạo và nhân bản và điều đó sẽ vi phạm SRP.
4. Thêm tài nguyên mới có tên 'CloneableResource' và thực hiện POST đến/CloneableResource/{resource_type}/{resource_source_id}. Ví dụ về nhân bản một con cừu, bạn sẽ tạo một POST tới/CloneableResource/Sheep/10. Bằng cách này, nó sẽ có thể dính vào việc sử dụng các phương thức HTTP tiêu chuẩn, sẽ không có xung đột với bất kỳ đường dẫn tài nguyên nào khác (hoặc vi phạm SRP). Tuy nhiên, tôi sẽ thêm một loại mới và có khả năng thừa cho miền. Tôi cũng không thể nghĩ ra một kịch bản khi người tiêu dùng muốn thực hiện bất kỳ điều gì khác ngoài POST cho tài nguyên này, do đó, nó có vẻ như một mùi mã với tôi.
5. Phương thức GET/resources/{id}? = Clone. Một trong những lợi thế ở đây là không có tài nguyên bổ sung nào được yêu cầu và nó có thể được xác định bởi tham số truy vấn tùy chọn đơn giản. Tôi biết rằng một trong những rủi ro ở đây là có thể nguy hiểm khi cung cấp khả năng đăng bài hoặc xóa bằng phương thức GET nếu URL nằm trong trang web vì nó có thể được công cụ tìm kiếm thu thập thông tin.

Cảm ơn bạn đã được trợ giúp!

Answer 1

Chịu ảnh hưởng của yêu cầu dự án và phạm vi tùy chọn giữa các thành viên trong nhóm của tôi, tùy chọn 1 sẽ phục vụ chúng tôi tốt nhất ở giai đoạn này.

• Phù hợp với các phương thức HTTP chuẩn sẽ đơn giản hóa và làm rõ API của tôi
• Sẽ có một cách tiếp cận phù hợp duy nhất để nhân bản một tài nguyên. Điều này lớn hơn vấn đề tôi có với việc chỉ định công việc nhân bản cho người tiêu dùng.

Answer 2

Nếu bạn muốn COPY một tài nguyên, thì, có, COPY là một lựa chọn hiển nhiên.

(và có, sẽ tốt nếu bạn kéo các định nghĩa COPY và MOVE ra khỏi RFC 4918 để gỡ rối chúng khỏi WebDAV).

Answer 3

Hầu hết các tùy chọn này là lựa chọn hoàn toàn tốt. Rất nhiều nó chỉ là sự lựa chọn phong cách của bạn cuối cùng. Dưới đây là nhận xét của tôi về từng tùy chọn của bạn.

1. từ bỏ trách nhiệm của nhân bản đối tượng tài nguyên cho người tiêu dùng
   Nói chung tôi không thực sự có một vấn đề với giải pháp này. Tùy chọn này rất thẳng về phía trước để người dùng hiểu và triển khai. Nó có thể là tốt hơn so với đến với một số chức năng nhân bản độc quyền mà người dùng của bạn phải học cách sử dụng.

2. Sử dụng các phần mở rộng HTTP WebDAV mà cung cấp một phương pháp COPY
   Tôi muốn dính vào phương pháp chuẩn là tốt. Tôi sẽ không sử dụng COPY, nhưng tôi sẽ không kinh hãi nếu bạn đã làm.

3. gửi bài đến/{} tài nguyên? ResourceIdToClone = {id}
   Đây là một giải pháp hoàn toàn tốt. Từ quan điểm REST, bạn không thực sự xung đột với phần còn lại của API của mình. URI có tham số truy vấn xác định tài nguyên khác với URI không có tham số truy vấn. Tham số truy vấn là tính năng URI để xác định tài nguyên mà bạn không thể tham chiếu theo thứ bậc. Tuy nhiên, có thể khó phân tách chúng trong mã của bạn vì cách mà hầu hết các khung công tác REST làm việc. Bạn có thể làm một cái gì đó tương tự như thế này ngoại trừ với một URI phân cấp như /{resource}/clone. Bạn có thể BÀI ĐĂNG cho URI này và chuyển số resource_source_id vào trong cơ thể.

4. Thêm một tài nguyên mới gọi là 'CloneableResource' và thực hiện một POST để/CloneableResource/{resource_type}/{resource_source_id}
   Không có gì sai với phương pháp này từ một quan điểm Văn là, nhưng tôi nghĩ rằng việc thêm một mới loại là cả hai không cần thiết và clutters API. Tuy nhiên, tôi không đồng ý với trực giác của bạn có thể có vấn đề với việc có một tài nguyên mà chỉ có một hoạt động POST. Nó xảy ra. Trong thế giới thực, không phải mọi thứ đều phù hợp với GET, PUT hoặc DELETE.

5. Một GET chống/tài nguyên/{id}? Method = bản sao
   Đây là lựa chọn duy nhất của 5 mà tôi không thể bỏ qua. Có vẻ như từ mô tả của bạn rằng bạn đã hiểu tại sao đây là một ý tưởng tồi, vì vậy tôi không chắc chắn lý do tại sao bạn đang xem xét nó. Tuy nhiên, tất cả những gì bạn phải làm để làm cho một giải pháp tốt là thay đổi GET thành POST. Sau đó nó trở nên rất giống với giải pháp # 3. URI cũng có thể phân cấp thay vì sử dụng tham số truy vấn. POST /resource/{id}/clone cũng sẽ hoạt động.

Tôi hy vọng điều này hữu ích. chúc may mắn với quyết định của bạn.