Để bao gồm ID tài nguyên trong tải trọng hoặc xuất phát từ URI

Thiết kế API, chúng tôi đã đưa ra câu hỏi liệu tải trọng PUT có nên chứa ID của tài nguyên đang được cập nhật hay không.

Đây là những gì chúng tôi hiện đang có:

PUT /users/123 Payload: {name: "Adrian"}

Mã lộ trình của chúng tôi trích xuất ID từ URI và tiếp tục với bản cập nhật.

Những người dùng API đầu tiên của chúng tôi đang đặt câu hỏi tại sao chúng tôi không cho phép ID trong tải trọng:

PUT /users/123 Payload: {id: 123, name: "Adrian"}

Lý do chúng tôi không cho phép là vì ID bị trùng lặp, trong tải trọng và URI.

Suy nghĩ thêm về điều này, chúng tôi đang ghép tài nguyên với URI.

Nếu URI không có ID, tải trọng sẽ cần được sửa đổi:

PUT /no/id/here Payload: {name: "Adrian"} < What user???

Có bất kỳ lý do để không?

Bạn phải ghép cặp Mã định danh tài nguyên thống nhất với tài nguyên .

Khi REST được triển khai với HTTP, bạn sử dụng GET để lấy giá trị hiện tại của tài nguyên và PUT để đặt giá trị mới. GET không có tải trọng, do đó, tài nguyên phải được xác định bởi URI. Và PUT được thực hiện một cách hợp lý cho cùng một URI và tải trọng sẽ trông chính xác như những gì bạn muốn GET tiếp theo trả về.

Bạn có thể sử dụng POST cho các URI khác nhau, nhưng nó sẽ chỉ có ý nghĩa ít hơn vì nó sẽ không đối xứng một cách không cần thiết với GET. POST cho URI thông thường chỉ có thể có ý nghĩa trong việc tạo tài nguyên mới ( POST /users/new, tải trọng : {name: "Adrian"}, phản hồi {id: 345, name: "Adrian"}), nhưng đó không phải là idempotent và do đó nên tránh nếu bạn đang phấn đấu cho REST¹. Thay vào đó, bạn nên đặt trước ID với một cuộc gọi và sau đó sử dụng PUT để đặt ID mới; đó là khả năng chịu lỗi, bởi vì nếu yêu cầu đầu tiên không thành công, việc đặt trước ID cuối cùng có thể hết thời gian và PUTkhông có kết quả. Hoặc sử dụng UUID do khách hàng tạo.

Definition Định nghĩa của REST không nói bất cứ điều gì về tính không ổn định, vì vậy tôi thực sự không thể khẳng định đó không phải là REST nếu bạn có các hoạt động không bình thường. Điều đó không thay đổi thực tế rằng việc tuân thủ các yêu cầu tạm thời làm cho mọi thứ trở nên đáng tin cậy hơn mà không làm phức tạp chúng và do đó được khuyến nghị.

Suy nghĩ thêm về điều này, chúng tôi đang ghép tài nguyên với URI.

Nếu URI không có ID, tải trọng sẽ cần được sửa đổi:

PUT / no / id / here Tải trọng: {name: "Adrian"} <Người dùng nào ???

Có bất kỳ lý do để không?

Câu trả lời cho câu hỏi này phụ thuộc vào việc bạn có muốn cho phép khách hàng thay đổi ID không?

Nếu khách hàng có thể thay đổi ID, thông qua PUT, thì URI cho tài nguyên sẽ thay đổi và bạn nên cung cấp 301 Đã di chuyển vĩnh viễn bất cứ khi nào tài nguyên truy cập vào URI cũ.

Vì vậy, ví dụ bạn bắt đầu với một tài nguyên tại

/users/123

và khách hàng PUT sau đây vào tài nguyên

{id: 222, name: "Adrian"}

tài nguyên đã được cập nhật và URI của nó hiện

/users/222

Các Locationtrường trong phản ứng PUT nên chứa URI mới, và nếu bạn đi đến /users/123bạn sẽ nhận được một 301phản ứng với lĩnh vực Location trỏ đến mới /users/222tài nguyên.

Trong hầu hết các trường hợp mặc dù bạn không thực sự muốn khách hàng có thể thay đổi ID, vì điều này có thể trở nên khá lộn xộn khá nhanh. Trong trường hợp đó, ID là thứ mà chỉ máy chủ mới có thể thay đổi và bạn nên để nó ra khỏi thân PUT, vì máy khách không thể cập nhật trạng thái này.

Nếu bạn đặt yêu cầu cho một URI khác trên cùng một tài nguyên, hãy nói

/users/adian_lync

sau đó nếu tài nguyên đó không tồn tại, máy chủ sẽ tạo nó và tạo và ID khi nó đang thực hiện