Bắt đầu thực sự với REST

Question

Tôi trình duyệt xung quanh cho một ví dụ phong nha về một API REST đơn giản, đầy đủ, không có kết quả. Kiểm tra trên stackoverflow là tốt. Điều tốt nhất tôi đã thấy là this post. Mặc dù vậy, tôi vẫn không hiểu. Hãy lấy một ví dụ về một ứng dụng mà chúng ta đều biết: wikipedia.

Giả sử chúng tôi muốn tạo một API REST cho wikipedia. Chúng tôi hy vọng các động từ sau:

GET /wiki/Article_name: obtains a specified page 
DELETE /wiki/Article_name: deletes the page 
POST /wiki/Article_name: creates a new page 
PUT /wiki/Article_name: updates a page. 

Thực tế là khi bạn sử dụng wikipedia với trình duyệt, bạn không sử dụng giao diện REST để điều hướng nó. Tôi khá chắc chắn rằng khi bạn cập nhật một trang, bạn không bao giờ sử dụng PUT (mặc dù bạn đang tạo một bản chỉnh sửa mới của một trang, vì vậy POST có ý nghĩa). Tương tự, khi bạn xóa một trang, trình duyệt không gửi một DELETE.

Câu hỏi của tôi là:

• là REST của cũng một giao diện "cho trình duyệt" hay chỉ cho các kịch bản?
• chúng ta có nên thấy thế giới HTTP độc quyền thông qua con mắt của một đại diện REST? những thứ như GET/foo /? page = bar & action = xóa vẫn còn một quan điểm hợp lệ, hoặc những sai lầm khủng khiếp của quá khứ không bao giờ được thực hiện một lần nữa?
• nên truy cập web và giao diện REST được xen kẽ hoặc tách biệt? Ví dụ, giả sử bạn có một ứng dụng AddressBook. Bạn có thể duyệt sổ địa chỉ bằng GET/people /, và với GET/people/1523, bạn có được thông tin người đó trên trình duyệt, có thể là một HTML có thể in đẹp. Nếu bạn muốn sửa đổi thẻ của mình, bạn sẽ làm (RESTfully) PUT/người/1523 hoặc thay vào đó có PUT /api/v1.0/people/1523?
• bất kỳ ai cũng có thể thuyết phục Roy Fielding lấy con người và cung cấp một ví dụ "5 tuổi" cho API REST, instead of complaining về những gì không phải là RESTful (theo ý kiến ​​của ông), để tất cả thế giới có thể làm theo?

Answer 1

EDIT1: Như tôi thấy trên thế giới, đối với hầu hết các lập trình viên REST là một khái niệm sẽ là xem xét khi tạo API. Vì vậy, REST nằm trong danh sách việc cần làm của bạn khi bạn tạo API cho mức tiêu thụ theo máy; KHÔNG phải khi bạn đang nói về các trang web mà con người sẽ tương tác thông qua trình duyệt. EDIT2: Và điều đó không ngụ ý rằng trình duyệt không phải là RESTful (có nghĩa là). Tôi chỉ có nghĩa là nơi mà hành động hiện tại là, nơi mà hầu hết các lập trình viên thế giới (những người không làm việc cho một nhà sản xuất trình duyệt) có thể hưởng lợi từ REST chủ yếu là trong các dịch vụ web.

Hãy lấy ví dụ về ứng dụng mà chúng ta đều biết: wikipedia.

OK, nhưng đây không phải là ví dụ hay nhất - Wikipedia là trang web phong phú, tức là trang web có nội dung phong phú dành cho con người chứ không phải máy tính.

GET/wiki/ARTICLE_NAME: có được một trang nào đó

DELETE/wiki/ARTICLE_NAME: xóa trang

POST/wiki/ARTICLE_NAME: tạo ra một trang mới

PUT/wiki/Article_name: cập nhật trang.

Cơ sở hạ tầng của bạn dựa trên mô hình sử dụng con người cho Wikipedia, do đó sự nhầm lẫn.

Tôi đang cung cấp ví dụ nhanh về API cho Wikipedia dưới đây, hy vọng nó sẽ giúp minh họa quan điểm của tôi. Nó được thực hiện rất nhanh chóng; và tôi không tuyên bố nó là một thiết kế API tốt. :-)

Lưu ý 1: Trong ví dụ API bên dưới, tôi đang sử dụng JSON. Theo như "RESTfulness" có liên quan, nó không phải là JSON, bất kỳ định dạng dữ liệu nào có thể được trao đổi một cách có ý nghĩa qua HTTP đều ổn. Các ví dụ khác có thể là XML, TXT, JPEG, AVI. Nói chung, "RESTfulness" áp dụng cho các tiêu đề URL và HTTP, không phải cho nội dung trang - phần thân còn lại miễn phí cho các nhu cầu triển khai cụ thể.

Lưu ý 2: Tôi giả sử Wikipedia có định dạng dữ liệu có cấu trúc nội bộ được chuyển thành trang HTML - chỉ để minh họa quan điểm của tôi, vì Wikipedia không thực sự là ví dụ tốt nhất để làm việc với ...

một phát súng đầu tiên tại một API RESTful cho Wikipedia có thể là một cái gì đó như:

api.wikipedia.com/search/keywords

Mất một GET với các từ tìm kiếm trong URL, trả lại tập dữ liệu JSON là ID trang, tiêu đề trang, URL và điểm liên quan.

api.wikipedia.com/article/id/

Mất một GET, xóa, POST, PUT, và sẽ hoạt động trên các bài viết với ID nội bằng "id" trong URL.Tùy thuộc vào phương thức HTTP của yêu cầu, nó sẽ:

1. GET; bài viết trả về (trong định dạng dữ liệu dựa trên JSON được xác định trước của Wikipedia.)
2. DELETE; xóa bài viết
3. BÀI; tạo bài viết mới (bài viết phải ở trong phần yêu cầu, theo định dạng JSON được xác định trước)
4. PUT; bài viết cập nhật (và toàn bộ trang phải được gửi một lần nữa trong cơ thể)

api.wikipedia.com/media/id/

Là "bài viết" thiết bị đầu cuối trên, nhưng đối với CRUD của phương tiện truyền thông như vậy như hình ảnh. .. v.v., cho đến khi tất cả nhu cầu của API Wikipedia tưởng tượng này được đáp ứng.

Xem lướt qua API tưởng tượng ở trên cho thấy một số vấn đề .. và đó là vẻ đẹp của REST; nó là đơn giản và không nhận được trong cách trực quan hóa dữ liệu exhange.

là REST cũng là giao diện "cho trình duyệt " hoặc chỉ dành cho tập lệnh?

EDIT3 Văn bản gốc là: Nó không dành cho trình duyệt, nó chỉ dành cho các API dành cho tiêu thụ bởi khách hàng hay dịch vụ mà là 'máy' khác.

Tôi muốn thay đổi điều này để: Trình duyệt là RESTful. Nó cũng là một sự cho phép, tức là với cơ sở đã cài đặt, và lượng thời gian cần thiết để IE6 được thay thế, rõ ràng là các trình duyệt mà chúng ta có ngày nay sẽ ở với chúng ta trong một thời gian dài. Và các trình duyệt hiện tại không làm bất cứ điều gì đặc biệt với microformats hoặc các trang web có XHTML để hiển thị trang và XHTML để truyền dữ liệu, chúng để lại tất cả những gì bạn thực hiện thông qua Javascript.

Vì vậy, với các công nghệ hiện tại, hầu hết sự phát triển mới áp dụng REST là xây dựng các API dịch vụ web tốt hơn. Và cân nhắc thực tế sẽ khiến mọi người chọn đặt API dịch vụ web của họ trên một URL khác với trang web chính của họ.

Tương đối so với các công nghệ dịch vụ web khác, REST có lợi thế đáng kể trong việc gỡ lỗi dễ dàng. Bạn chỉ có thể kích hoạt ứng dụng khách trên PC, gửi URL và xem phản hồi ngay lập tức. (OK, điều tương tự cũng áp dụng ở một mức độ nào đó đối với nhiều dịch vụ web dựa trên XML; nhưng XML do máy tạo ra là không thực tế đối với tôi để 'đọc'.)

chúng ta nên xem thế giới HTTP độc quyền thông qua con mắt của một đại diện REST?

Ehh, no. Trình duyệt xử lý, những gì, 97% lưu lượng truy cập trang web của ngày hôm nay là trung bình?

nên truy cập web và giao diện REST được xen kẽ hoặc tách biệt?

riêng, trong ví dụ trên tôi đã sử dụng api.wikipedia.com để minh họa rằng nó hoàn toàn tách biệt với trang web Wikipedia thường xuyên. Để cân nhắc thực tế, chẳng hạn như cân bằng tải, lịch phát hành khác nhau, các yêu cầu kinh doanh khác nhau.

Answer 2

Bạn đang ngâm mình trong đó.

Có, GET, PUT, POST và DELETE là tất cả các cuộc gọi RESTful. Hầu hết thời gian, bạn đang sử dụng GET hoặc POST. Khi bạn truy cập URL, yêu cầu GET được gửi tới máy chủ web. Khi bạn gửi biểu mẫu, đó có thể là GET hoặc POST, tùy thuộc vào yếu tố. Tuy nhiên, DELETE và PUT là các cuộc gọi hoàn toàn hợp lệ trong các trường hợp thích hợp, như WebDAV. The HTTP page có thể xóa một số điều đó.

REST, cho trẻ 5 tuổi, chỉ có nghĩa là "Máy khách gửi yêu cầu tới máy chủ để thay đổi trạng thái (thêm/thay thế/xóa/truy xuất một số nội dung, trong trường hợp HTTP) và máy chủ trả lời (Vì vậy, gần như ANY cuộc gọi thông thường tới một máy chủ web là RESTful, có thể là từ trình duyệt của bạn, từ JavaScript, hoặc REST từ thường đến cổng 80 từ một chương trình đầu cuối

REST thường được sử dụng trái với SOAP, trong đó dịch vụ web có khả năng mô tả chính nó và API của nó cho khách hàng, và các dịch vụ web có thể được tìm thấy từ các thư mục. phức tạp hơn nhiều. phần lớn, nếu bạn không làm SOAP (và xà phòng quá phức tạp, bạn không thể làm điều đó mà không biết về nó), bạn đang làm REST.

Trong khi tôi đang giải quyết sự tương phản, một số buzzwordaholics sẽ tương phản REST thành AJAX. Chúng hoàn toàn trực giao và hoàn toàn có thể sử dụng các kỹ thuật AJAX để thực hiện các yêu cầu REST hoặc các yêu cầu SOAP.AJAX, cho trẻ 5 tuổi, có nghĩa là có một số phần mềm chạy trong trình duyệt (có thể là JavaScript, nhưng cũng có thể là Java hoặc Flash) thực hiện yêu cầu HTTP tới máy chủ và xử lý phản hồi thay vì chính trình duyệt , do đó, màn hình không thay đổi cho đến khi chương trình máy khách chạy trong trình duyệt quyết định sửa đổi DOM của trang hiện đang được hiển thị.

Đối với câu hỏi của bạn về việc GET có phải là ý tưởng hay không, "điều đó phụ thuộc". GET đặt toàn bộ yêu cầu trong chuỗi truy vấn. Điều đó có nghĩa là nếu đó là yêu cầu mà người dùng muốn thực hiện lại một lần nữa (nói đó là trang tìm kiếm hoặc liên kết đến một bài đăng trên blog cụ thể), nó có thể được đánh dấu trang. Nhược điểm là chuỗi truy vấn chỉ có thể quá dài và có thể dẫn đến người dùng đánh dấu các phần của URL mà họ không nên. POST, mặt khác, có thể gửi nội dung hầu như vô hạn, nhưng bạn không thể đánh dấu nó hoặc gửi một URL cho một người bạn (hoặc kẻ thù, tùy thuộc vào liên kết). Bạn phải sử dụng một trong những quyền cho tình hình. Đôi khi bạn cần có Philips, đôi khi bạn cần thiết bị flathead.

Ví dụ về GET/people/1523 và PUT/people/1523 của bạn là hoàn toàn hợp lệ, mặc dù khó thực hiện với máy chủ web thông thường, điều này sẽ không hiểu bạn muốn PUT làm gì. "mọi người" sẽ phải là một chương trình ở một số ngôn ngữ phía máy chủ có thể xử lý yêu cầu. Nếu bạn đang sử dụng Java Servlets, nó có thể được ánh xạ tới Servlet của bất kỳ tên nào. Sẽ dễ dàng hơn để tách động từ yêu cầu HTTP khỏi động từ hoạt động dữ liệu của bạn, như GET/people/1523/get và POST/people/1523/update (hoặc GET/people/get/1523 và POST/people/update/1523).

Answer 3

Một số trình duyệt hiện đại vẫn không thể gửi bất kỳ yêu cầu HTTP nào ngoại trừ GET và POST. Nó chặn sự chấp nhận rộng rãi hơn của REST. Mặc dù một số công việc xung quanh cho các trình duyệt có sẵn (xem this presentation bởi David Heinemeier Hansson).

Theo Tim Berners-Lee, URL phải mờ đục (mặc dù có some debate here), vì vậy những thứ như GET /foo/?bar=baz HTTP/1.1 hoàn toàn OK theo như GET vẫn không có giá trị và an toàn.

Việc sử dụng lại URL bằng cách truy cập chúng bằng các loại phương tiện khác nhau được coi là một phương pháp hay.

Tôi nghĩ rằng người ta có thể sử dụng RFC 5023 The Atom Publishing Protocol làm ví dụ kinh điển về API RESTful (ít nhất Roy Fielding đã nhận xét về một số vấn đề liên quan đến nó).

Answer 4

câu trả lời từng phần:?

là những thứ như GET/foo/page = thanh & action = vẫn xóa một điểm hợp lệ xem, hoặc sai lầm khủng khiếp của quá khứ không bao giờ được thực hiện một lần nữa?

Chắc chắn sau. Theo như tôi biết, thậm chí không có bất kỳ cuộc tranh luận nào về điểm này. Yêu cầu GET phải là idempotent. Sử dụng GET để thực hiện xóa là một hành vi lạm dụng khủng khiếp trên web và tôi sẽ cười bất mãn khi có ai thực hiện khi Googlebot xuất hiện và xóa cơ sở dữ liệu của họ.

Giữ công cụ tìm kiếm không làm bạn thất vọng là KHÔNG lý do duy nhất không thực hiện việc này, do đó, không nhận được bất kỳ ý tưởng điên rồ nào về việc này chỉ vì bạn thực hiện việc xác thực.

Nếu bạn muốn có nút xóa, có nút xóa. Nếu bạn thực sự, thực sự muốn nút trông giống như một liên kết, hãy sử dụng javascript để thực hiện nhấp vào liên kết thực hiện một bài đăng (hoặc tạo liên kết GET một trang xác nhận, điều này hoàn toàn có thể chấp nhận được).

Answer 5

là REST của cũng một giao diện "cho trình duyệt " hay chỉ cho các kịch bản

Cả. Trong thực tế, trình duyệt thực sự là một ví dụ tuyệt vời của một máy khách REST. Thực tế là nó chỉ sử dụng một tập con của giao diện HTTP không vi phạm ràng buộc giao diện thống nhất. POST là khá nhiều một động từ ký tự đại diện anyway. Các kịch bản được định nghĩa trong mô tả của REST dưới dạng "tải xuống mã" và đóng một phần không thể tách rời của giao diện REST.

Cập nhật: Ràng buộc giao diện thống nhất của REST không nói "bạn phải sử dụng tất cả các động từ có sẵn" để được RESTful. Nó nói nếu bạn sử dụng một động từ, sử dụng nó để thực hiện một hành động phù hợp với hành vi mong đợi.

chúng ta có nên xem thế giới HTTP độc quyền thông qua con mắt của đại diện REST không?

No. REST thường được thực hiện qua HTTP, nhưng HTTP không phụ thuộc vào REST. Tuy nhiên, nếu bạn đang xây dựng một ứng dụng web thì bạn nên nghiêm túc xem xét việc chọn kiểu kiến ​​trúc REST cho giải pháp của bạn. Nó có thể không phải là lựa chọn đúng, nhưng nó có thể sẽ là.

Yêu cầu GET /foo/?page=bar&action=delete vi phạm các quy tắc của HTTP và do đó phá vỡ ràng buộc REST của giao diện đồng nhất. Nhưng nó phá vỡ HTTP đầu tiên!

Cập nhật: Trong HTTP đặc tả RFC 2616 phần 9.1.1 nó khẳng định: "Đặc biệt, quy ước đã được thành lập rằng GET và ĐẦU phương pháp KHÔNG NÊN có tầm quan trọng của thi một hành động khác hơn so với hồi. " Thực hiện hành động xóa bằng cách sử dụng GET chắc chắn sẽ phá vỡ các quy tắc của HTTP.

nên truy cập web và giao diện REST được xen kẽ hoặc tách biệt?

Theo tôi, chúng phải giống nhau. Trong thực tế XHTML thực sự là một định dạng tuyệt vời để sử dụng để cung cấp cả kết quả UI và API. Nó được chuẩn hóa, nó có thể dễ dàng phân tích, nó có thể xem được trong trình duyệt nhằm mục đích gỡ lỗi, nó có thể hỗ trợ hypermedia, microformats có thể được sử dụng để đánh dấu ngữ nghĩa, thuộc tính lớp có thể được sử dụng để xác định những thứ mà microformats không bao gồm. Bạn có cần gì nữa không?

Nếu bạn dự định thực hiện giao diện người dùng HTML, tại sao lại thực hiện công việc tương tự hai lần?

Roy có thể cho chúng tôi một mẫu đơn giản không?

Đọc bài viết How to GET a cup of coffee để có ý tưởng tốt về cách REST API hoạt động.

Khi đọc bài viết nhớ sự kiện này quan trọng mà tất cả mọi người dường như đã quên:

giao diện REST của nên dễ sử dụng, họ không dễ dàng để thiết kế.

Answer 6

Hãy nhớ rằng REST không có gì hơn là một tập hợp các ràng buộc kiến ​​trúc cho máy tính phân tán, độc lập với bất kỳ giao thức truyền tải cơ bản nào. Khi đánh giá RESTfullness của một tương tác máy khách-máy chủ, bạn đang thực sự kiểm tra xem một hoặc nhiều các contraints này có bị hỏng hay không.

là REST cũng là giao diện "cho trình duyệt" hoặc chỉ dành cho tập lệnh?

Khi bạn duyệt Wikipedia bằng Firefox, bạn đang kiểm soát ứng dụng khách REST. Việc thiếu hỗ trợ cho PUT và DELETE không làm giảm các RESTfullnes của tương tác vì ý nghĩa của các động từ HTTP nằm ngoài phạm vi của REST. Một điểm đáng ngờ hơn có thể là cách mà các trang web và trình duyệt hỗ trợ phiên. Khi mỗi yêu cầu phải được hiểu trong ngữ cảnh của một phiên, bạn có thể nói rằng sự ràng buộc của tình trạng không quốc tịch của các yêu cầu bị phá vỡ.

chúng ta có nên thấy thế giới HTTP độc quyền thông qua con mắt của đại diện REST không? những thứ như GET/foo /? page = bar & action = xóa vẫn còn một quan điểm hợp lệ, hoặc những sai lầm khủng khiếp của quá khứ không bao giờ được thực hiện một lần nữa?

AFAIK, điều này không tự phá vỡ ràng buộc REST, trừ khi cùng một kết hợp URI/động từ thực hiện hai điều khác nhau. Trong trường hợp đó, bạn sẽ phá vỡ ràng buộc giao diện thống nhất. Tôi muốn nói rằng cách tiếp cận này là xấu từ quan điểm của deviating từ ý định của giao thức HTTP, nhưng không phải từ quan điểm của REST.

nên truy cập web và giao diện REST được xen kẽ hoặc tách biệt? Ví dụ, giả sử bạn có một ứng dụng AddressBook. Bạn có thể duyệt sổ địa chỉ bằng GET/people /, và với GET/people/1523, bạn có được thông tin người đó trên trình duyệt, có thể là một HTML có thể in đẹp. Nếu bạn muốn sửa đổi thẻ của mình, bạn sẽ làm (RESTfully) PUT/người/1523 hoặc thay vào đó có PUT /api/v1.0/people/1523?

Tôi không thấy sự cố với API RESTful hoạt động khác với trình duyệt và cho các ứng dụng REST khác. Điều quan trọng nhất là cung cấp hành vi nhất quán trên một lớp khách hàng. Phiên bản API nằm ngoài phạm vi của REST.

bất kỳ ai cũng có thể thuyết phục Roy Fielding lấy con người và cung cấp một ví dụ "5 tuổi" cho API REST thay vì phàn nàn về những gì không RESTful (theo ý kiến ​​của ông), để tất cả thế giới có thể theo dõi?

Đây chính xác là cảm giác của tôi sau khi đọc bài đăng đó và đưa ra chống lại việc thiếu các ví dụ thực tế gần như thiếu.

Đề xuất của Darrel Miller cho cốc cà phê là một điều tốt. Nếu bạn muốn đơn giản hơn, chỉ cần quay lại ví dụ ban đầu của bạn - trình duyệt. Mỗi đứa trẻ tôi đã nhìn thấy bằng cách sử dụng một trình duyệt Web nhanh chóng hiểu cách nó hoạt động. Bạn bắt đầu trên một số trang. Bạn tìm thấy một cái gì đó bạn thích. Bạn theo liên kết. Bạn đến trang khác. Bạn tìm thấy một cái gì đó bạn thích ở đó. Bạn theo liên kết đó và đến trang khác. Và cứ thế.

Thật buồn cười khi được chứng minh là giảm ý tưởng đơn giản này để thực hành cho khách hàng không có trình duyệt. Để có cảm hứng, bạn có thể xem qua số Sun Cloud API.

Answer 7

• NerdDinner.com
• The Sun Cloud API
• Twitter
• Paul Jame's article
• MediaWiki's API

---

1. NerdDinner sử dụng WCF Data Services, một cách tuyệt vời để thực hiện đúng các dịch vụ RESTful. Lý do tôi chỉ ra rằng, và không phải WCF dịch vụ dữ liệu trực tiếp là bởi vì nó là một trang web công cộng và bạn có thể sử dụng nó. 2. MediaWiki không phải là một ví dụ tuyệt vời vì chúng đang truyền các hành động trong URI nhưng về mặt kỹ thuật là một dịch vụ RESTful và hiển thị rất nhiều ý tưởng thú vị.