RESTful API thiết kế hoạt động tốt nhất

Question

Tôi hiện viết một lớp API cho dự án của tôi, và đang phải vật lộn với cố gắng tìm ra một phương pháp thiết kế tốt cho các tình huống sau:

1. Tất cả người dùng có một danh sách những cuốn sách
2. Mỗi danh sách có thể được truy cập thông qua một ID
3. người dùng có thể thêm và xóa sổ theo ý

Hiện nay, tôi không chắc chắn đó là cách tiếp cận tốt nhất sẽ là:

012.

1) PUT - /api/list/{listID}/{bookID} - Add book to specified list 
    DELETE - /api/list/{listID}/{bookID} - Remove book from specified list 
2) PUT - /api/list/{listID} - Send XML data to server that contains bookID and action 
    <list_payload> 
     <action>{delete|add}</action> 
     <bookID>{bookID}</bookID> 
    </list_payload> 

Mọi thông tin chi tiết sẽ được đánh giá cao.

Answer 1

Tôi nghĩ như thế này

1)POST - /api/lists/{listID}/books - Add book to specified list 
2)PUT - /api/lists/{listID}/books/{bookID} - Edit book from a specified list 
3)DELETE - /api/lists/{listID}/books/{bookID} - delete 

cho Danh sách

POST - /api/lists Add list 
PUT - /api/lists/{listID} Edit list 
DELETE /api/lists/{listID} Delete list 

Answer 2

Không có ràng buộc trong REST vì đây là cách giải quyết mọi thứ qua HTTP và không phải là giao thức dịch vụ web cứng với tiêu chuẩn mạnh như SOAP.

Nói rằng, cả hai tùy chọn có thể hợp lệ nhưng vì mục đích đơn giản, tôi nghĩ bạn phải đi theo tùy chọn đầu tiên của mình.

Answer 3

tôi sẽ giải thích các ví dụ đầu tiên khi bạn đang cập nhật cuốn sách đó tồn tại trong danh sách. Có nghĩa là, cuốn sách đã tự đặt dữ liệu, nhưng trong danh sách, nó có nhiều thuộc tính mà bạn có thể cập nhật thông qua địa chỉ {listID}/books/{bookID}.

Nếu bạn muốn cập nhật nội dung của danh sách (ví dụ: thêm hoặc xóa sách), hãy gọi PUT theo địa chỉ danh sách/{listID} có ý nghĩa nhất đối với tôi.

-Dan

Answer 4

Tôi nghĩ đây là hướng dẫn rất tốt và rõ ràng để hiểu cách thiết kế một dịch vụ REST thích hợp. Nó không chỉ bao gồm câu hỏi này mà còn cung cấp thêm đầu mối cho quá trình thiết kế.

Bạn có thể xem: https://www.youtube.com/watch?v=hdSrT4yjS1g Hoặc bạn có thể xem nhanh: http://www.slideshare.net/stormpath/rest-jsonapis

Answer 5

Như @MartinRevert chỉ ra, có thực sự là không có những hạn chế về thiết kế REST API khác hơn so với những bạn đặt vào chính mình.

Đối với bản thân mình, tôi khuyên bạn nên tập trung vào khả năng thử nghiệm và phát triển UI đơn giản hơn là tận dụng tất cả các khả năng của giao thức HTTP. Cuối cùng, họ là khách hàng của bạn và nếu khung JavaScript của họ không tuân thủ tất cả các quy ước tài nguyên HTTP (Angular didn't for the 201 Created redirect in an earlier version)

GET là để truy xuất dữ liệu. Chủ yếu là vì nó có thể được lưu trữ. Điều này sẽ trả về dữ liệu của loại nội dung thích hợp.

POST sẽ sửa đổi dữ liệu hoặc chấp nhận truy vấn tìm kiếm phức tạp. Trong hợp đồng của tôi, điều này sẽ luôn là trả lại đối tượng JSON.

Bằng cách giữ mọi thứ chỉ là POST, bạn có thể tạo biểu mẫu đơn giản mà không phải thực hiện công cụ XHR để thực hiện một số thử nghiệm chức năng.

Tôi đã viết một sâu sắc hơn câu trả lời ở đây http://www.trajano.net/2014/07/rest-api-contract/

Answer 6

Dưới đây là một liên kết đến một dịch vụ JSON thử nghiệm với một liên kết tải về mã nguồn cho cả web và Android: http://developersfound.com/RESTExperiment/restExperiment.html

Tôi đã làm một nhiều mã thử nghiệm trong thời gian rảnh rỗi của tôi với REST. Tôi đã sử dụng và thử nghiệm khá nhiều khung công tác gần đây và tôi đã đi vòng tròn đầy đủ và nhận ra rằng HTTP JSon đơn giản là hiệu quả nhất. Hầu hết mọi người nói rằng statelessness là lợi thế của REST nhưng HTTP cũng không trạng thái. HTTP có lợi thế nhất là có trạng thái nếu bạn cần; trạng thái kết nối hoặc trạng thái phiên. Nó cũng an toàn hơn. Tuy nhiên, nếu bạn khăng khăng đi xuống tuyến đường REST, hãy thử tìm một khung công cụ định tuyến không sử dụng các tuyến tùy chỉnh; điều đó phụ thuộc vào các biểu thức chính quy vì điều này đặt gánh nặng lớn lên các máy chủ. Định tuyến biểu thức không chính quy đặt một chút hạn chế đối với cách bạn thiết kế và phát triển dịch vụ của bạn, nhưng nó đáng giá nếu bạn coi trọng các máy chủ nhanh với các tắc nghẽn tối thiểu. Một cách tuyệt vời khác để giảm thiểu tắc nghẽn là sử dụng các thủ tục được lưu trữ thay vì truy vấn thông qua. Đối với những người bạn không biết truy vấn thông qua là gì. Nó hoàn toàn trái ngược với việc sử dụng các thủ tục lưu sẵn, khi nhà phát triển tự động tạo ra một chuỗi SQL tại máy chủ và chuyển nó tới cơ sở dữ liệu. Các thủ tục được lưu trữ loại bỏ các tắc nghẽn vì các truy vấn pass-through khiến máy chủ tự động tạo sql mỗi lần máy chủ bị tấn công. Với các thủ tục được lưu trữ, bạn chỉ cần chuyển các tham số từ yêu cầu trực tiếp đến cơ sở dữ liệu. Các thủ tục lưu sẵn cũng được biên dịch nghĩa là ngay cả cơ sở dữ liệu cũng không phải tạo SQL động. Các truy vấn pass-through đã trở thành di sản khi chuẩn SQL 92 xuất hiện vào năm 1992. Liên kết tôi có ở trên thực sự là mã thử nghiệm nhưng bạn sẽ thấy blog rất sâu sắc.