Differences between Servlet and Restlet

5 messages Options
Embed this post
Permalink
Dan Drillich

Differences between Servlet and Restlet

Reply Threaded More More options
Print post
Permalink
Good Day,

We have here an internal conversation about the subject. Therefore, what are the benefits of using Web Services and in particular Restlets instead of Servlets?

Regards,
Dan
Rob Heittman

Re: Differences between Servlet and Restlet

Reply Threaded More More options
Print post
Permalink
Part 1 - Why web services and/or REST?

I think the seminal work on this subject is still the Richardson and Ruby book (which also covers Restlet), RESTful Web Services, http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260

There's a Manning book coming out about Restlet soon, Restlet in Action.  If you don't mind surrendering your email address you can get a teaser here: http://www.manning.com/free/green_louvel.html  (Hey Jerome, tell Manning their process doesn't work with Chrome ... I only got 1 page)

I personally prefer a style of application design in which you first create a semantic API that solves the functional aspects of your problem, then expose user interfaces or additional convenience APIs so that people or programs can take advantage of it.  This is not the only design process choice, but has always worked best for me.  If you are making web applications and want to try this design process, web services are not an extra value-add feature, but an intrinsic element of the process.

Part 2 - Servlet vs Restlet

Servlet is intentionally very simple, and provides a minimum set of capabilities for writing Web-connected server side code generally in a standardized way -- somewhat on the same level as CGI, FastCGI, Ruby Rack, Python WSGI.

Restlet is a richer API for the specific purpose of building RESTful web services and aims to model the higher level concepts of the Web's RESTful architecture.  To write a RESTful web application using only Servlet:

 - A lot of code needs to be created to properly handle complex things like conditional GETs or content negotiation.  So many Servlet developers just don't.  Restlet's ServerResource model handles these nicely with minimal hints needed from the developer.
 - To set headers, etc., you need to know the proper strings to use and the nuances of their formatting.  This can be frustrating, add bloat, and be hard to test.  Restlet provides a lot of classes that correctly model the concepts used in HTTP.  If the usage is wrong, it probably won't compile.
 - It's usual REST practice to take advantage of hierarchical URI space to map server side resources.  With Servlet alone, it's necessary to make some sort of routing scaffold to find and execute the correct target.  Restlet provides a nice routing mechanism.

Of course there are other frameworks and applications you might be using that would give you some or all of these advantages.  Restlet is very lightweight at its core and very focused on its task.  So it is easy to introduce Restlet into just about any environment (embedded, JEE, Swing, OSGi ...) to simplify the creation of RESTful server services and improve their correctness.  This is why I like it; my team and I can write portable web service code and have it work in lots of different environments.

I suspect, based on list traffic, that the predominant means of using Restlet is not *instead of* Servlet but in *addition to* it.  Folks use Restlet running on GAE or any of the horde of JEE app servers, to wrap RESTful services.

For those of us iconoclasts who don't need any Servlet API at all, Restlet can talk directly to the low level services of Jetty, Simple, Netty (new shiny thing), and other Java HTTP servers, to take advantage of their specific optimizations and skip some extra translation on every request.

Looking at it one way, Restlet slows things down and adds complexity to Servlet.  Looking at it another way (the way I *do* look at it), Restlet models a lot of stuff I need to model anyway in every application, and does it in a very well tested way, backed by a crowd of smart and diligent engineers.  This makes my web services much more responsive, efficient, and bug-free than they would be if I created all that myself, or if I coerced a non-REST-oriented framework into service.

- R

On Fri, Oct 30, 2009 at 10:10 AM, Dan Drillich <[hidden email]> wrote:
Good Day,

We have here an internal conversation about the subject. Therefore, what are
the benefits of using Web Services and in particular Restlets instead of
Servlets?

Regards,
Dan

--
View this message in context: http://n2.nabble.com/Differences-between-Servlet-and-Restlet-tp3919100p3919100.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413005

Dan Drillich

Re: Differences between Servlet and Restlet

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)
Many thanks Rob for your answer.
 
Regards,
Dan


From: Rob Heittman [via Restlet Discuss] <[hidden email]>
To: Dan Drillich <[hidden email]>
Sent: Fri, October 30, 2009 11:08:05 AM
Subject: Re: Differences between Servlet and Restlet

Part 1 - Why web services and/or REST?

I think the seminal work on this subject is still the Richardson and Ruby book (which also covers Restlet), RESTful Web Services, http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260

There's a Manning book coming out about Restlet soon, Restlet in Action.  If you don't mind surrendering your email address you can get a teaser here: http://www.manning.com/free/green_louvel.html  (Hey Jerome, tell Manning their process doesn't work with Chrome ... I only got 1 page)

I personally prefer a style of application design in which you first create a semantic API that solves the functional aspects of your problem, then expose user interfaces or additional convenience APIs so that people or programs can take advantage of it.  This is not the only design process choice, but has always worked best for me.  If you are making web applications and want to try this design process, web services are not an extra value-add feature, but an intrinsic element of the process.

Part 2 - Servlet vs Restlet

Servlet is intentionally very simple, and provides a minimum set of capabilities for writing Web-connected server side code generally in a standardized way -- somewhat on the same level as CGI, FastCGI, Ruby Rack, Python WSGI.

Restlet is a richer API for the specific purpose of building RESTful web services and aims to model the higher level concepts of the Web's RESTful architecture.  To write a RESTful web application using only Servlet:

 - A lot of code needs to be created to properly handle complex things like conditional GETs or content negotiation.  So many Servlet developers just don't.  Restlet's ServerResource model handles these nicely with minimal hints needed from the developer.
 - To set headers, etc., you need to know the proper strings to use and the nuances of their formatting.  This can be frustrating, add bloat, and be hard to test.  Restlet provides a lot of classes that correctly model the concepts used in HTTP.  If the usage is wrong, it probably won't compile.
 - It's usual REST practice to take advantage of hierarchical URI space to map server side resources.  With Servlet alone, it's necessary to make some sort of routing scaffold to find and execute the correct target.  Restlet provides a nice routing mechanism.

Of course there are other frameworks and applications you might be using that would give you some or all of these advantages.  Restlet is very lightweight at its core and very focused on its task.  So it is easy to introduce Restlet into just about any environment (embedded, JEE, Swing, OSGi ...) to simplify the creation of RESTful server services and improve their correctness.  This is why I like it; my team and I can write portable web service code and have it work in lots of different environments.

I suspect, based on list traffic, that the predominant means of using Restlet is not *instead of* Servlet but in *addition to* it.  Folks use Restlet running on GAE or any of the horde of JEE app servers, to wrap RESTful services.

For those of us iconoclasts who don't need any Servlet API at all, Restlet can talk directly to the low level services of Jetty, Simple, Netty (new shiny thing), and other Java HTTP servers, to take advantage of their specific optimizations and skip some extra translation on every request.

Looking at it one way, Restlet slows things down and adds complexity to Servlet.  Looking at it another way (the way I *do* look at it), Restlet models a lot of stuff I need to model anyway in every application, and does it in a very well tested way, backed by a crowd of smart and diligent engineers.  This makes my web services much more responsive, efficient, and bug-free than they would be if I created all that myself, or if I coerced a non-REST-oriented framework into service.

- R

On Fri, Oct 30, 2009 at 10:10 AM, Dan Drillich <[hidden email]> wrote:
Good Day,

We have here an internal conversation about the subject. Therefore, what are
the benefits of using Web Services and in particular Restlets instead of
Servlets?

Regards,
Dan

--
View this message in context: http://n2.nabble.com/Differences-between-Servlet-and-Restlet-tp3919100p3919100.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413005




View message @ http://n2.nabble.com/Differences-between-Servlet-and-Restlet-tp3919100p3919480.html
To unsubscribe from Differences between Servlet and Restlet, click here.


jlouvel

RE: Differences between Servlet and Restlet

Reply Threaded More More options
Print post
Permalink
In reply to this post by Rob Heittman
Some javascript/style in this post has been disabled (why?)

Hi Rob,

 

Another excellent reply!

 

Regarding the issue with the green paper and Chrome, I have just reported it to Manning. BTW, the book should be entering their MEAP this week!

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~
http://www.noelios.com

 

 

 

 

De : Rob Heittman [mailto:[hidden email]]
Envoyé : vendredi 30 octobre 2009 16:08
À : [hidden email]
Objet : Re: Differences between Servlet and Restlet

 

Part 1 - Why web services and/or REST?

 

I think the seminal work on this subject is still the Richardson and Ruby book (which also covers Restlet), RESTful Web Services, http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260

 

There's a Manning book coming out about Restlet soon, Restlet in Action.  If you don't mind surrendering your email address you can get a teaser here: http://www.manning.com/free/green_louvel.html  (Hey Jerome, tell Manning their process doesn't work with Chrome ... I only got 1 page)

 

I personally prefer a style of application design in which you first create a semantic API that solves the functional aspects of your problem, then expose user interfaces or additional convenience APIs so that people or programs can take advantage of it.  This is not the only design process choice, but has always worked best for me.  If you are making web applications and want to try this design process, web services are not an extra value-add feature, but an intrinsic element of the process.

 

Part 2 - Servlet vs Restlet

 

Servlet is intentionally very simple, and provides a minimum set of capabilities for writing Web-connected server side code generally in a standardized way -- somewhat on the same level as CGI, FastCGI, Ruby Rack, Python WSGI.

 

Restlet is a richer API for the specific purpose of building RESTful web services and aims to model the higher level concepts of the Web's RESTful architecture.  To write a RESTful web application using only Servlet:

 

 - A lot of code needs to be created to properly handle complex things like conditional GETs or content negotiation.  So many Servlet developers just don't.  Restlet's ServerResource model handles these nicely with minimal hints needed from the developer.

 - To set headers, etc., you need to know the proper strings to use and the nuances of their formatting.  This can be frustrating, add bloat, and be hard to test.  Restlet provides a lot of classes that correctly model the concepts used in HTTP.  If the usage is wrong, it probably won't compile.

 - It's usual REST practice to take advantage of hierarchical URI space to map server side resources.  With Servlet alone, it's necessary to make some sort of routing scaffold to find and execute the correct target.  Restlet provides a nice routing mechanism.

 

Of course there are other frameworks and applications you might be using that would give you some or all of these advantages.  Restlet is very lightweight at its core and very focused on its task.  So it is easy to introduce Restlet into just about any environment (embedded, JEE, Swing, OSGi ...) to simplify the creation of RESTful server services and improve their correctness.  This is why I like it; my team and I can write portable web service code and have it work in lots of different environments.

 

I suspect, based on list traffic, that the predominant means of using Restlet is not *instead of* Servlet but in *addition to* it.  Folks use Restlet running on GAE or any of the horde of JEE app servers, to wrap RESTful services.

 

For those of us iconoclasts who don't need any Servlet API at all, Restlet can talk directly to the low level services of Jetty, Simple, Netty (new shiny thing), and other Java HTTP servers, to take advantage of their specific optimizations and skip some extra translation on every request.

 

Looking at it one way, Restlet slows things down and adds complexity to Servlet.  Looking at it another way (the way I *do* look at it), Restlet models a lot of stuff I need to model anyway in every application, and does it in a very well tested way, backed by a crowd of smart and diligent engineers.  This makes my web services much more responsive, efficient, and bug-free than they would be if I created all that myself, or if I coerced a non-REST-oriented framework into service.

 

- R

 

On Fri, Oct 30, 2009 at 10:10 AM, Dan Drillich <[hidden email]> wrote:

Good Day,

We have here an internal conversation about the subject. Therefore, what are
the benefits of using Web Services and in particular Restlets instead of
Servlets?

Regards,
Dan

--
View this message in context: http://n2.nabble.com/Differences-between-Servlet-and-Restlet-tp3919100p3919100.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413005

 

Rob Heittman

Re: Differences between Servlet and Restlet

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)
Some more info ... Not necessarily Chrome but Chrome OS X preview ... It attempts first to open the PDF in a broken internal browser.  Then because the download ticket is a one time thing, you can't re-download in a non broken way.  Making the ticket work a few times or for a few minutes would help.



On Nov 2, 2009, at 6:13 AM, Jerome Louvel <[hidden email]> wrote:

Hi Rob,

 

Another excellent reply!

 

Regarding the issue with the green paper and Chrome, I have just reported it to Manning. BTW, the book should be entering their MEAP this week!

 

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~
http://www.noelios.com

 

 

 

 

De : Rob Heittman [mailto:[hidden email]]
Envoyé : vendredi 30 octobre 2009 16:08
À : [hidden email]
Objet : Re: Differences between Servlet and Restlet

 

Part 1 - Why web services and/or REST?

 

I think the seminal work on this subject is still the Richardson and Ruby book (which also covers Restlet), RESTful Web Services, http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260

 

There's a Manning book coming out about Restlet soon, Restlet in Action.  If you don't mind surrendering your email address you can get a teaser here: http://www.manning.com/free/green_louvel.html  (Hey Jerome, tell Manning their process doesn't work with Chrome ... I only got 1 page)

 

I personally prefer a style of application design in which you first create a semantic API that solves the functional aspects of your problem, then expose user interfaces or additional convenience APIs so that people or programs can take advantage of it.  This is not the only design process choice, but has always worked best for me.  If you are making web applications and want to try this design process, web services are not an extra value-add feature, but an intrinsic element of the process.

 

Part 2 - Servlet vs Restlet

 

Servlet is intentionally very simple, and provides a minimum set of capabilities for writing Web-connected server side code generally in a standardized way -- somewhat on the same level as CGI, FastCGI, Ruby Rack, Python WSGI.

 

Restlet is a richer API for the specific purpose of building RESTful web services and aims to model the higher level concepts of the Web's RESTful architecture.  To write a RESTful web application using only Servlet:

 

 - A lot of code needs to be created to properly handle complex things like conditional GETs or content negotiation.  So many Servlet developers just don't.  Restlet's ServerResource model handles these nicely with minimal hints needed from the developer.

 - To set headers, etc., you need to know the proper strings to use and the nuances of their formatting.  This can be frustrating, add bloat, and be hard to test.  Restlet provides a lot of classes that correctly model the concepts used in HTTP.  If the usage is wrong, it probably won't compile.

 - It's usual REST practice to take advantage of hierarchical URI space to map server side resources.  With Servlet alone, it's necessary to make some sort of routing scaffold to find and execute the correct target.  Restlet provides a nice routing mechanism.

 

Of course there are other frameworks and applications you might be using that would give you some or all of these advantages.  Restlet is very lightweight at its core and very focused on its task.  So it is easy to introduce Restlet into just about any environment (embedded, JEE, Swing, OSGi ...) to simplify the creation of RESTful server services and improve their correctness.  This is why I like it; my team and I can write portable web service code and have it work in lots of different environments.

 

I suspect, based on list traffic, that the predominant means of using Restlet is not *instead of* Servlet but in *addition to* it.  Folks use Restlet running on GAE or any of the horde of JEE app servers, to wrap RESTful services.

 

For those of us iconoclasts who don't need any Servlet API at all, Restlet can talk directly to the low level services of Jetty, Simple, Netty (new shiny thing), and other Java HTTP servers, to take advantage of their specific optimizations and skip some extra translation on every request.

 

Looking at it one way, Restlet slows things down and adds complexity to Servlet.  Looking at it another way (the way I *do* look at it), Restlet models a lot of stuff I need to model anyway in every application, and does it in a very well tested way, backed by a crowd of smart and diligent engineers.  This makes my web services much more responsive, efficient, and bug-free than they would be if I created all that myself, or if I coerced a non-REST-oriented framework into service.

 

- R

 

On Fri, Oct 30, 2009 at 10:10 AM, Dan Drillich <[hidden email]> wrote:

Good Day,

We have here an internal conversation about the subject. Therefore, what are
the benefits of using Web Services and in particular Restlets instead of
Servlets?

Regards,
Dan

--
View this message in context: http://n2.nabble.com/Differences-between-Servlet-and-Restlet-tp3919100p3919100.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413005