Làm thế nào phổ biến là phục hồi?

Question

Tôi đang chọn một khuôn khổ cho dịch vụ an toàn. Restlet trông đầy hứa hẹn. Tuy nhiên, tôi muốn chọn thứ gì đó đủ chính thống để nó không sớm được hỗ trợ/phát triển. Tôi biết restlet đã được khoảng một vài năm. Tuy nhiên, tôi muốn biết nếu nó đủ phổ biến. Câu hỏi của tôi là,

1. Bất kỳ công ty lớn nào sử dụng tên?
2. Máy chủ http mặc định có đủ tốt để sản xuất không?

nhờ

Answer 1

Từ article

API Servlet được phát hành vào năm 1998 và thiết kế cốt lõi của nó đã không thay đổi đáng kể từ thời điểm đó. Đây là một trong số các API Java EE thành công nhất của , nhưng nó bị thiếu một số lỗi thiết kế và giới hạn . Ví dụ: ánh xạ giữa các mẫu URI và các trình xử lý bị giới hạn và tập trung trong một tệp cấu hình. Ngoài ra, nó cho phép kiểm soát các luồng ổ cắm trực tiếp đến nhà phát triển ứng dụng , ngăn chặn một số tối ưu hóa IO bằng các thùng chứa Servlet như sử dụng đầy đủ các tính năng NIO. Cuối cùng, nó không hỗ trợ HTTP các tính năng như lưu vào bộ nhớ đệm, đàm phán nội dung và nén nội dung rất tốt, gây ra quá nhiều đau cho các nhà phát triển và ngăn chúng thành tập trung vào mã ứng dụng cụ thể của họ.

Một mối quan tâm lớn khác là thiếu API ứng dụng khách HTTP hiện đại trong ngăn xếp Java EE . Lớp HttpURLConnection của JDK khó sử dụng và để lại quá nhiều tính năng HTTP không được hỗ trợ như thể hiện khách hàng tùy chọn cho thương lượng nội dung.

Thông thường, mọi người đang dựa vào API ứng dụng HTTP của bên thứ ba để giải quyết những hạn chế đó. Một lần nữa, NIO không thể được hỗ trợ với HttpURLConnection.

Năm 2005, tôi thấy cơ hội vượt qua tất cả những hạn chế đó và để thiết kế API mới theo nguyên tắc REST. Đối với lần đầu tiên, chúng tôi có API hợp nhất phía máy khách và ứng dụng web phía máy khách, API hỗ trợ đầy đủ NIO và API cho phép nhà phát triển lập trình kiểm soát vùng chứa, trình kết nối và các ứng dụng được triển khai mà không cần phải liên tục dựa vào các mô tả XML .

Answer 2

Dòng chính bạn có thể nhận được là Jersey. Đó là việc thực hiện chính thức phần còn lại trong java. Restlet xuất hiện trước Jersey. Nhưng rồi Jersey vượt qua họ (theo ý kiến ​​khiêm nhường của tôi). Tôi đã sử dụng cả Jersey và Restlet cho các dự án nghiêm túc. Cả hai đều tốt. Tuy nhiên, bạn sẽ tìm thấy nhiều hỗ trợ hơn, nhiều sách hơn và nhiều ví dụ khác về Jersey.

Answer 3

Đây có phải là về Java không? Trong trường hợp đó, JAX-RS là API mới tuyệt vời để thực hiện việc này. Cuốn sách tốt nhất cho điều này là Restful Java with JAX-RS. Thực hiện yêu thích của tôi của nó là Jersey, nhưng có những người khác với các tính năng độc đáo của riêng họ. Tất cả các triển khai JAX-RS đều tương thích nếu bạn không sử dụng các tính năng đặc biệt của chúng (dù là nhỏ). Cuốn sách giải thích API cốt lõi, triết lý REST và một số tính năng duy nhất cho các triển khai khác nhau.Đó là một cuốn sách tuyệt vời. Tôi thích phần giới thiệu, nơi tác giả liên hệ cách ông được sử dụng để gọi thủ tục từ xa truyền thống (như SOAP, WCF, và ngữ nghĩa OO bình thường) nhưng sau đó thấy ánh sáng của các nguyên tắc REST đơn giản và thanh lịch hơn.

Tôi sử dụng Tomcat làm máy chủ HTTP (thùng chứa servlet). Nó là trọng lượng nhẹ và là những gì Amazon Beanstalk sử dụng (bạn chỉ có thể tải lên ứng dụng của bạn, tệp WAR, cho nó và nó chỉ hoạt động). Bạn cũng có thể sử dụng GlassFish hỗ trợ nhiều tính năng JavaEE khác, hoặc sử dụng Apache cho các trang tĩnh và các thứ khác, và chuyển tiếp các yêu cầu REST tới Tomcat/GlassFish.

Điều gây phiền nhiễu về JAX-RS là nó rất mạnh mẽ và dễ dàng khiến bạn bị cám dỗ khi viết các dịch vụ REST mang tính ý thức hệ tư tưởng. Thật không may, javascript không thể sử dụng nhiều tính năng REST (thiết lập chấp nhận tiêu đề, gọi bất cứ điều gì nhưng GET/POST, vv) Nhưng nó không phải là một việc lớn.

Jersey cũng có một API Java phía máy khách tuyệt vời phản ánh JAX-RS và sử dụng lại các lớp được chú thích giống nhau, nếu khách hàng của bạn sẽ là Java.

Answer 4

Khung Restlet đã có sẵn từ năm 2005 khi nó là khung công tác web RESTful đầu tiên cho Java. Nó có hỗ trợ cho API JAX-RS, nhưng API Restlet riêng của nó là cả máy khách và phía máy chủ kể từ ngày đầu tiên, toàn diện hơn và có thể mở rộng hơn. Chúng tôi được tự do đổi mới dựa trên nguồn cấp dữ liệu cộng đồng của chúng tôi, mà không phải trải qua quá trình tiêu chuẩn hóa JCP kéo dài.

Ngoài ra, chúng tôi vừa xuất bản cuốn sách 'Restlet in Action' vào tháng 9 năm ngoái cùng với phiên bản 2.1. Trình kết nối nội bộ của chúng tôi hoàn toàn không đồng bộ và dựa trên NIO và chúng tôi liên tục ổn định nó mặc dù chưa sẵn sàng cho việc sản xuất nặng (sử dụng trình kết nối Jetty hoặc một thùng chứa Java EE mà không thay đổi ứng dụng Restlet của bạn).

Hỗ trợ nhất quán cho Java SE/EE, OSGi, Android, GAE và GWT với các ấn bản chuyên dụng là duy nhất. Một cổng đến JS (Node.js + AJAX) cũng đang được tiến hành. Chúng tôi cũng đã bắt đầu làm việc trên phiên bản 2.2 với cột mốc đầu tiên được phát hành (với hỗ trợ đầy đủ Java 6, phần mở rộng OAuth 2.0 dựa trên thông số cuối cùng, v.v.).

Về tham chiếu, chúng tôi có nhiều công ty lớn sử dụng nó bao gồm LinkedIn (xem dự án mã nguồn mở GLU), IBM, NVidia, ForgeRock, NASA, Sonatype, Apache Camel, Mule ESB, v.v. trong nội bộ là tốt. Xem một số trích dẫn tại đây: http://restlet.com/discover/quotes

Vào tháng 1, chúng tôi sẽ khởi chạy một trang web cộng đồng mới cũng như APISpark, nền tảng tất cả trong một để tạo, lưu trữ, quản lý và sử dụng API web, trực tiếp dựa trên Restlet Khung (PaaS), vì vậy dự án đang hoạt động và có một tương lai thú vị!

Trân trọng,

Jerome Louvel

PS: Tôi là người sáng tạo Restlet Framework và phát triển dẫn.