Thiết kế uri còn lại để thay đổi trạng thái cho tài nguyên

Question

Tôi có tài nguyên có thể truy cập tại URI /resources/{resource_identifier} và có thuộc tính 'trạng thái' mà tôi muốn truy cập. Tôi đã nghĩ về một vài lựa chọn cho điều này, đó sẽ là 'tốt nhất' hay 'hầu hết các RESTfull'?

hành động Lựa chọn Một Nối vào URI và có khách hàng POST những URI

/resources/{resource_identifier}/void  
/resources/{resource_identifier}/open  
/resources/{resource_identifier}/close 

này trông vụng về mặc dù.

---

Lựa chọn Hai Sử dụng một tham số truy vấn trong URI và đã client PATCH những

/resources/{resource_identifier}?transition=void 
/resources/{resource_identifier}?transition=open 
/resources/{resource_identifier}?transition=close 

---

Lựa chọn Ba Sử dụng tải trọng của yêu cầu và có các khách hàng PUT

/resources/{resource_identifier} 

tùy chọn tải trọng:

{ ..., "status" :"void" } 
{ ..., "status" :"open" } 
{ ..., "status" :"close" } 

---

Hoặc có thể một cái gì đó khác hoàn toàn?

Answer 1

Tùy chọn thứ hai của bạn trông đẹp hơn vì bạn đang duy trì cấu trúc url RESTful và không thêm các phương thức kiểu RPC vào cuối phương thức đó.

Tại sao không chỉ làm điều này:

PUT-/resources/:id và gửi dữ liệu transition=void với yêu cầu.

Nó hoạt động theo cách tương tự nếu bạn nhận được yêu cầu POST, chỉ cần lấy dữ liệu ra khỏi phần yêu cầu.

Answer 2

Tại sao không có 'trạng thái' làm tài nguyên. Bạn có thể quản lý nó. Cũng giả sử rằng phải có 'trạng thái' được tạo như một phần của việc tạo tài nguyên {resource_identifier} và đã có giá trị mặc định cho trạng thái.

Sau đó, logic nghiệp vụ cần chỉ là 'cập nhật' trạng thái thông qua cuộc gọi còn lại và do đó nên sử dụng 'PUT'.

cập nhật Di chuyển trạng thái để các Put-Body

PUT: /resources/{resource_identifier}/status/ 

Body: {void | open | close } 

Answer 3

Tùy chọn đầu tiên rõ ràng là không nghỉ ngơi; bạn có 'hành động' trong URI và đang sử dụng POST, để tạo tài nguyên mới mà bạn không cố gắng thực hiện.

Chỉ xem định dạng URI bây giờ. Tùy chọn hai đang trở nên tốt hơn, nhưng các chuỗi truy vấn có tính chất đó nhiều hơn cho số đọc dữ liệu. Không có gì thực sự ngăn bạn làm theo cách này. Tùy chọn ba có định dạng URI tốt nhất, nó chỉ đề cập đến tài nguyên bạn muốn tham chiếu trong yêu cầu của bạn.

Nếu bây giờ chúng tôi xem xét phương pháp của yêu cầu. Trong cuốn sách của tôi, điều này khá đơn giản, tôi cho rằng trạng thái chỉ là một trường của tài nguyên này, và vì vậy nếu bạn chỉ thực hiện cập nhật từng phần, bạn đang vá tài nguyên, và do đó PATCH là phương thức để sử dụng. Về cơ hội tắt, 'trạng thái' là tài sản duy nhất, sau đó thay đổi trạng thái là hoàn toàn thay đổi tài nguyên và do đó PUT sẽ được chấp nhận; nhưng tôi nghi ngờ rằng thực sự là như vậy.

Vì nó đứng, các URI của tùy chọn thứ ba, kết hợp với việc sử dụng PATCH có lẽ là lựa chọn tốt nhất.

PATCH /resources/{resource_identifier} 

{ "status" :"close" } 

Tất nhiên, bạn cũng có thể kết hợp điều này với các khái niệm về lộ thuộc tính cụ thể thông qua URI của mình như thể chúng là một nguồn tài nguyên theo đúng nghĩa của họ. Thành thật mà nói, tôi không thích điều này, vì nó cảm thấy khá kỳ quặc và chỉ hoạt động cho một thuộc tính tại một thời điểm. Tuy nhiên, nếu đây là những gì bạn muốn sử dụng, bạn có thể có một cái gì đó như:

PUT /resources/{resource_identifier}/status 

close 

---

Hãy nhớ, không có "quyền" cách làm REST, chỉ là "not bad" cách. Đó là một phong cách, không phải là một bộ quy tắc.

Tôi cũng khuyên bạn nên xem xét việc có thể thực hiện nhiều định dạng là một tính năng mong muốn, nói chung. Như vậy, tùy chọn đầu tiên có xu hướng dễ làm việc hơn. Bạn có thể lấy JSON, như ví dụ có, hoặc hoán đổi nó thành XML <status>close</ status> hoặc một cặp giá trị khóa đơn giản status=closed v.v.