The greatest advantage is that it's ubiquitous by now. The biggest disadvantage is that it's a rather verbose protocol and thus not very efficient. In other words, it's easy to build a Web service engine on top of existing things because "everybody knows HTTP" and existing Web servers can be configured to forward certain HTTP requests to the engine. No need to open up yet another port from the firewall (then again, I don't see this as a big problem anyway).
Originally posted by Lasse Koskela: . No need to open up yet another port from the firewall (then again, I don't see this as a big problem anyway).
This can be seen as a big drawback too.. No need to open the firewall.... Ask your security administrator if he is pleased about the fact the http port can allow an external application to enter your system :-)
/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
posted 17 years ago
Originally posted by Jean-Louis Marechaux: This can be seen as a big drawback too.. No need to open the firewall.... Ask your security administrator if he is pleased about the fact the http port can allow an external application to enter your system :-)
True. The firewall is there for a purpose and if you have a good reason, you'll get the network admin to open up the port you want.
I would say the advantages of HTTP are: -well defined standard that is fairly easy to write clients and servers for -interoperable, cross-platform, cross-language, ubiquitous -caching, proxies, load balancing... there are lots of well-known and fairly easy ways to scale systems built around HTTP -the most used method [GET] is the most optimized, and the 1.1 protocol goes to great lengths to define how intermediate systems can cache objects -- following the HTTP principles gives you a lot of leverage to design your system to achieve maximum performance -for me, the GET, PUT, and DELETE operations are just like the actions I end up coding over and over in Stateless Session facades for Data Transfer Objects... -human and machine readable, just like XML (at least XML used to be... disadvantages: -plain text headers are somewhat inefficient (message bodies can be compressed and returned with a "Content-Encoding: gzip" entity header) risks: -corruption of the protocol by avoiding the core verbs (web services are too POST-centric for me) -web browser mentality: to really understand HTTP, stop thinking of browsers and servers, since browsers really only do GET and POST, most people aren't aware that PUT and DELETE are verbs they could be using... do a web search for: Representational State Transfer think of REST as using HTTP verbs (GET, PUT, POST, DELETE) to act on data objects, and you will have a solid foundation to build on. when you need something from another node, use GET when you want to store something to another node, use PUT when you want to remove something from another node, use DELETE when you want to change the state of an object on another node, use POST