Điều gì đang sử dụng URL RESTful mua cho tôi?

Question

Tôi đã đọc trên REST, và tôi đang cố gắng tìm ra những lợi thế để sử dụng nó. Cụ thể, lợi thế của các URL kiểu REST làm cho chúng có giá trị thực hiện trên một yêu cầu GET điển hình hơn với một chuỗi truy vấn là gì?

Tại sao URL này:

http://www.parts-depot.com/parts/getPart?id=00345 

coi thua kém này?

http://www.parts-depot.com/parts/00345 

Trong ví dụ trên (lấy từ here) URL thứ hai thực sự trông thanh lịch và ngắn gọn hơn. Nhưng nó có chi phí ... URL đầu tiên là khá dễ dàng để thực hiện trong bất kỳ ngôn ngữ web, ra khỏi hộp. Thứ hai yêu cầu mã bổ sung và/hoặc cấu hình máy chủ để phân tích các giá trị, cũng như tài liệu bổ sung và thời gian dành giải thích hệ thống cho các lập trình viên cơ sở và biện minh cho các đồng nghiệp. Vì vậy, câu hỏi của tôi là, ngoài niềm vui của việc có URL trông thật tuyệt, những lợi ích mà các URL RESTful giành được cho tôi mà sẽ làm cho việc sử dụng chúng đáng giá chi phí thực hiện?

Answer 1

Hy vọng là nếu bạn tạo URL của bạn tham khảo một danh từ thì có một cơ hội tốt hơn mà bạn sẽ thực hiện các động từ HTTP một cách chính xác. Ngoài ra, hoàn toàn không có lợi thế của một URL so với URL khác.

Thực tế là nội dung của URL hoàn toàn không liên quan đến hệ thống RESTful. Nó chỉ đơn giản là một định danh.

Nó không phải là những gì nó trông giống như, đó là những gì bạn làm với nó đó là quan trọng.

Answer 2

Một thứ mà tôi luôn thích là người dùng web hiểu biết, nhưng chắc chắn không nên được sử dụng làm nguyên tắc hướng dẫn khi sử dụng lược đồ URL đó là các loại URL đó là "có thể hack". Đặc biệt đối với những thứ như blog nơi tôi có thể chỉnh sửa ngày hoặc số trang trong URL thay vì phải tìm nút "trang tiếp theo" ở đâu.

Answer 3

Một cách nhìn REST:

http://tomayko.com/writings/rest-to-my-wife (mà hiện đã được đưa xuống, buồn bã, nhưng vẫn có thể được nhìn thấy trên web.archive.org)

Vì vậy, dù sao, HTTP này giao thức Fielding và những người bạn của anh ấy tạo ra — là tất cả về việc áp dụng động từ vào danh từ. Ví dụ: khi bạn truy cập trang web, trình duyệt thực hiện HTTP GET trên URL mà bạn nhập vào và quay lại có trang web.

...

Thay vào đó, phần lớn đang bận rộn lớp bằng văn bản về phức tạp thông số kỹ thuật để thực hiện công cụ này trong một cách khác đó là gần như không hữu ích hoặc hùng hồn. Danh từ không phải là phổ quát và động từ không phải là đa hình. Chúng tôi đang loại bỏ thập kỷ sử dụng thực tế và đã được chứng minh kỹ thuật và bắt đầu lại với một cái gì đó trông rất giống với các hệ thống khác không thành công trong quá khứ. Chúng tôi đang sử dụng HTTP nhưng chỉ vì nó giúp chúng tôi trao đổi với mạng của chúng tôi và số an ninh ít hơn . Chúng tôi đang giao dịch sự đơn giản cho các công cụ hào nhoáng và trình thuật sĩ.

Answer 4

Một điều nhảy ra ngoài với tôi (câu hỏi hay ho) là những gì họ mô tả. Đầu tiên mô tả một hoạt động (getPart), phần thứ hai mô tả một tài nguyên (phần 00345).

Ngoài ra, có thể bạn không thể sử dụng các động từ HTTP khác với phương thức đầu tiên - ví dụ: bạn cần một phương thức mới cho putPart.Thứ hai có thể được tái sử dụng với các động từ khác nhau (như PUT, DELETE, POST) để 'thao tác' tài nguyên? Tôi cho rằng bạn cũng kinda nói GET hai lần - một lần với động từ, một lần nữa trong phương pháp, do đó, thứ hai là phù hợp hơn với ý định của giao thức HTTP?

Answer 5

"Thứ hai đòi hỏi thêm đang và/hoặc cấu hình máy chủ để phân tích ra giá trị,"

Thật sao? Bạn chọn một khung làm việc nghèo nàn. Kinh nghiệm của tôi là phiên bản RESTful chính xác là cùng một lượng mã. Có lẽ tôi chỉ may mắn vào một khuôn khổ tuyệt vời.

"cũng như thêm tài liệu và thời gian dành cho việc giải thích hệ thống để các lập trình viên cơ sở"

Chỉ một lần. Sau khi họ nhận được nó, bạn không cần phải giải thích nó một lần nữa.

"và biện minh cho đồng nghiệp".

Chỉ một lần. Sau khi họ nhận được nó, bạn không cần phải giải thích nó một lần nữa.

Answer 6

Ưu điểm lớn nhất của REST IMO là nó cho phép một cách sạch sẽ để sử dụng các động từ HTTP (đó là quan trọng nhất trên các dịch vụ REST). Trên thực tế, sử dụng REST có nghĩa là bạn đang sử dụng giao thức HTTP và các động từ của nó.

Sử dụng url của bạn, và tưởng tượng bạn muốn gửi một "phần", thay vì nhận được nó

Trường hợp đầu tiên nên là như thế này:

Bạn đang sử dụng một GET nơi bạn nên đã sử dụng một bài

http://www.parts-depot.com/parts/postPart?param1=lalala&param2=lelele&param3=lilili 

trong khi trên một bối cảnh REST, nó phải được

http://www.parts-depot.com/parts 

một thứ trên cơ thể, (ví dụ) một xml như thế này

<part> 
    <param1>lalala<param1> 
    <param2>lelele<param1> 
    <param3>lilili<param1> 
</part> 

Answer 7

Ngữ nghĩa URI được xác định bởi RFC 2396. Các chất chiết xuất đặc biệt thích hợp cho câu hỏi này là 3.3. "Path Component":

Các thành phần đường dẫn chứa dữ liệu, cụ thể cho cơ quan (hoặc chương trình nếu không có thành phần chính quyền), xác định các nguồn trong phạm vi mà chương trình và thẩm quyền.

Và 3.4 "Query Component":

Thành phần truy vấn là một chuỗi các thông tin để được giải thích bởi tài nguyên.

Lưu ý rằng thành phần truy vấn không phải là một phần của mã định danh tài nguyên, nó chỉ là thông tin được giải thích bởi tài nguyên.

Như vậy, tài nguyên được xác định bằng ví dụ đầu tiên của bạn thực sự chỉ là /parts/getPart. Nếu bạn có ý định là URL phải xác định một phần tài nguyên cụ thể thì ví dụ đầu tiên không làm điều đó, trong khi ví dụ thứ hai (/parts/00345) thì không.

Vì vậy, 'lợi thế' của phong cách thứ hai của URL là nó có ngữ nghĩa chính xác, trong khi cái đầu tiên thì không.

Answer 8

Không sử dụng các phần truy vấn/tìm kiếm trong URL không phải là truy vấn hoặc tìm kiếm, nếu bạn làm điều đó - theo thông số URL - bạn có thể ngụ ý điều gì đó về tài nguyên mà bạn không thực sự muốn.

Sử dụng các phần truy vấn cho các tài nguyên là tập con của một số tài nguyên lớn hơn - phân trang là một ví dụ tốt về nơi áp dụng điều này.