Một tài nguyên đơn lẻ RESTful

Question

Tôi đến từ thế giới RPC nhưng hiện đang điều tra nếu sử dụng REST là một ý tưởng tốt cho dự án của tôi. Đối với như tôi hiểu từ Wikipedia ý tưởng cơ bản của các dịch vụ RESTful là cung cấp quyền truy cập vào các bộ sưu tập và các phần tử riêng lẻ của chúng.

Trong trường hợp của tôi, máy chủ sẽ là công cụ đo lường. Tôi phải có khả năng bắt đầu, dừng và tạm dừng thói quen đo lường, và đọc dữ liệu bất cứ lúc nào.

Hiện nay, tôi đang xem xét những điều sau đây:

• POST/biện pháp (bắt đầu đo lường, điều này tiếp tục cho đến khi dừng lại bởi người sử dụng)
• PUT/biện pháp pause = true/false (tạm dừng/hủy tạm)
• DELETE/biện pháp (ngừng)
• GET/biện pháp (lấy dữ liệu đo lường)

Tuy nhiên, tôi không chắc chắn nếu điều này phù hợp với mô hình REST, vì tôi không thực sự làm việc với các bộ sưu tập hoặc các phần tử ở đây.

Câu hỏi của tôi: Làm cách nào để truy cập vào tài nguyên đơn lẻ và thực hiện yêu cầu bắt đầu/dừng đối với máy chủ có phá vỡ ràng buộc không trạng thái RESTful?

Answer 1

Bạn vẫn đang làm việc trên một tài nguyên và cách bạn chia nhỏ nó nghe có vẻ tốt với tôi. Fielding đề cập rõ ràng các dịch vụ tạm thời trong REST chapter:

Sự trừu tượng hóa thông tin chính trong REST là tài nguyên. Bất kỳ thông tin có thể được đặt tên có thể là một tài nguyên: một tài liệu hoặc hình ảnh, một dịch vụ thời gian (ví dụ: "thời tiết hôm nay tại Los Angeles")

Có lẽ nó sẽ làm cho tinh thần để cung cấp cho mỗi phép đo một id duy nhất mặc dù . Bằng cách đó, bạn có thể tham khảo duy nhất từng phép đo (bạn thậm chí không phải lưu trữ các phép đo cũ, nhưng nếu ai đó đề cập đến một phép đo cũ, bạn có thể nói với chúng, rằng những gì chúng yêu cầu không được cập nhật nữa).

Answer 2

Xây dựng dựa trên câu trả lời cuối cùng. Đây là cách bạn có thể muốn phá vỡ nó xuống

• biện pháp/- GET tất cả các biện pháp từ các nhạc cụ (Đánh số trang/giới hạn nếu cần dựa vào thông số truy vấn)
• biện pháp /: measure_id - GET một biện pháp đặc biệt
• các biện pháp/- BÀI ĐĂNG - Bắt đầu một biện pháp mới. Điều này trả về ID đo lường mới mà bạn có thể xử lý sau này.
• các biện pháp /: measure_id - DELETE - ngừng đo lường.
• các biện pháp /: measure_id - PUT - cập nhật biện pháp
• các biện pháp/last_measure - Tài nguyên được đo lường lần cuối.

Answer 3

Không RESTful

Không, cách tiếp cận của bạn là không yên tĩnh, bởi vì nếu tôi hiểu được quy trình làm việc, bạn sẽ xóa các tài nguyên để ngăn chặn sự đo lường và sau đó nhận được các nguồn tài nguyên để đọc ra kết quả cuối cùng. Nhưng việc xóa tài nguyên ngụ ý rằng sẽ không có gì còn lại để GET.

Thực tế là tài nguyên của bạn là một singleton không phải là vấn đề gì cả. Vấn đề nằm ở cách bạn lập bản đồ động từ và trạng thái.

Mô tả của bạn là một chút trừu tượng, vì vậy hãy cẩn thận hơn một chút: giả sử rằng công cụ được đề cập đo tốc độ góc của bánh xe bay theo radian/giây. Công cụ này có một số chi phí liên quan đến đo lường, vì vậy khách hàng cần có khả năng vô hiệu hóa việc đo lường trong một khoảng thời gian như một biện pháp tiết kiệm chi phí. Nếu điều này gần giống với kịch bản của bạn, thì giải thích dưới đây sẽ được áp dụng cho kịch bản của bạn.

Động từ

Bây giờ, hãy xem lại động từ của bạn.

GET trả về đại diện cho tài nguyên. Vì vậy, khi bạn GET /measure, nó sẽ trả lại một số dữ liệu đại diện cho phép đo hiện tại.

PUT tạo hoặc cập nhật tài nguyên cụ thể, được đặt tên. Tài nguyên được đặt tên theo URL của tài nguyên. Vì vậy, PUT /measure ngụ ý rằng bạn đang cập nhật trạng thái của tài nguyên có tên là /measure hoặc tạo tài nguyên đó nếu tài nguyên chưa tồn tại. Trong trường hợp của bạn, giá trị công cụ là chỉ đọc: chúng tôi không thể ghi giá trị radian/sec cho công cụ. Nhưng trạng thái bị tạm dừng/hoạt động của công cụ này có thể thay đổi, do đó, PUT /measure phải bao gồm nội dung sửa đổi trạng thái của công cụ. Bạn có thể sử dụng nhiều biểu diễn khác nhau ở đây, nhưng một cách tiếp cận đơn giản sẽ là một cơ quan yêu cầu như active=true hoặc active=false để cho biết trạng thái mới của công cụ này là gì.

POST tương tự như PUT, ngoại trừ khách hàng không chỉ định tên của tài nguyên sẽ được tạo hoặc cập nhật. Trong một API khác, ví dụ, khách hàng có thể POST /articles để tạo một bài viết mới. Máy chủ sẽ tạo một tài nguyên và đặt tên cho nó là /articles/1234 và sau đó nó sẽ thông báo cho khách hàng về tên mới này bằng cách trả lại mã HTTP 201 CREATED và thêm tiêu đề Location: /articles/1234 để cho khách hàng biết nguồn tài nguyên mới ở đâu. Trong trường hợp của bạn, POST không phải là một động từ có ý nghĩa bởi vì bạn luôn biết tên của tài nguyên singleton của bạn là gì.

DELETE có nghĩa là bạn xóa tài nguyên và vì tài nguyên được xác định bằng URL, DELETE /measure ngụ ý rằng /measure không còn tồn tại nữa. Số GET /measure tiếp theo phải trả lại 404 NOT FOUND hoặc 410 GONE. Trong trường hợp của bạn, khách hàng thực sự không thể phá hủy công cụ, do đó, DELETE không có ý nghĩa là một động từ có ý nghĩa.

Kết luận

Vì vậy, trong Tóm lại, một thiết kế RESTful cho dịch vụ của bạn sẽ được để có PUT /measure với một cơ thể yêu cầu mà nói với các công cụ cho dù đó nên hoạt động hay không hoạt động (tạm dừng) và GET /measure để đọc các đo lường hiện tại .Nếu bạn GET /measure trên một công cụ bị tạm dừng, có thể bạn nên trả lại trạng thái HTTP 409 CONFLICT. Dịch vụ của bạn không được sử dụng POST hoặc DELETE.