2013-02-14 59 views
9

Tôi đang viết API HATEOAS RESTful. Tôi có các thực thể phức hợp mà tôi phải GET, POST và PUT. Phần GET rất dễ dàng và có rất nhiều ví dụ. Phản hồi chứa các thuộc tính nguyên thủy của thực thể và các liên kết đến các thực thể lồng nhau. Ví dụ:Yêu cầu POST HTTP trong API RESTFul HATEOAS

{ 
"id":"2", 
"firstName":"Brad", 
"lastName":"Pitt", 
"balance":1234.5, 
"transactions":"http://localhost:8080/jersey-poc/api/v1.1/account/1/transactions", 
"self":"http://localhost:8080/api/v1.1/account/1", 
"accountType":"http://localhost:8080/api/v1.1/account/1/accountType" 
} 

Vấn đề nảy sinh khi tôi muốn tạo hoặc sửa đổi tài khoản. Tôi cần liên kết tài khoản với một AccountType. Tôi có thể gửi yêu cầu POST như sau: {"firstName":"Michael","lastName":"Jackson","balance":300.0,"accountTypeId":5}
nhưng điều đó sẽ phá vỡ mô hình HATEOAS. Thực hành tốt nhất cho các thực thể phức hợp POST/PUT là gì?

Trả lời

4

Không có gì đặc biệt về tải trọng đó sẽ chống lại HATEOAS; vấn đề thực sự duy nhất là accountTypeId không phải là rất dễ phát hiện. (Các ID Magic luôn tốt hơn khi được ánh xạ thành các chuỗi mô tả ngắn; hãy nghĩ về chúng như một kiểu liệt kê.) Một trong những điều quan trọng cần nhớ khi làm việc với mô hình HATEOAS là thực thể mà POST người dùng không cần phải là chính xác thực thể tạo tài nguyên; bạn có thể sửa đổi nó, chú thích nó, dịch nó. Nó vẫn phải là khái niệm giống nhau, nhưng hoàn toàn khác với việc là giống hệt nhau. (Thêm ID và dấu thời gian tạo ra sẽ là những ví dụ tuyệt vời về cách mở rộng sẽ hoàn toàn hợp lý.)

Với tôi nó có vẻ như vấn đề thực sự của bạn là bạn cần xem xét lại những thông tin khách hàng cần gửi khi thực hiện POST. bạn có ý định thông báo cho khách hàng rằng họ nên gửi thông tin đó khi thực hiện POST. Bản thân tôi, tôi khá thích sử dụng XML để tải lên ở đây, vì tôi có thể dễ dàng nói với khách hàng rằng tải trọng POST của họ phải phù hợp với một lược đồ cụ thể (và cả Lược đồ XML và RELAX NG đủ để tôi mô tả các ràng buộc). Tôi chắc chắn đó không phải là cách duy nhất để làm điều đó.

+0

Cảm ơn. Giải thích nó. Tôi chắc chắn rằng yêu cầu và phản hồi phải giống nhau. –

Các vấn đề liên quan