SOAP, REST, RPC

 http://stackoverflow.com/questions/409338/examples-of-the-best-soap-rest-rpc-web-apis-and-why-do-you-like-them-and-what

http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/

 REST web services are:

• Lightweight – not a lot of extra xml markup
• Human Readable Results
• Easy to build – no toolkits required

SOAP also has some advantages:

• Easy to consume – sometimes
• Rigid – type checking, adheres to a contract
• Development tools

(OReilly.RESTful.Web.Services.May.2007)

SOAP
a typical SOAP service keeps its method information in the entity-body
and in a HTTP header.

Example Request Message:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
  </soap:Header>
  <soap:Body>
    <m:GetStockPrice xmlns:m="http://www.example.org/stock">
      <m:StockName>IBM</m:StockName>
    </m:GetStockPrice>
  </soap:Body>
</soap:Envelope>

Example Response Message:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStockPriceResponse>
    <m:Price>34.5</m:Price>
  </m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope> 

RESTful
In RESTful architectures, the method information goes into the HTTP method. In Resource-
Oriented Architectures, the scoping information goes into the URI. The combination
is powerful

If the HTTP method doesn't match the method information, the service isn’t RESTful. If the scoping information
isn’t in the URI, the service isn’t resource-oriented. These aren't the only requirements,
but they're good rules of thumb.

RPC
An RPC-style web service accepts an envelope full of data from its client, and sends a
similar envelope back. The method and the scoping information are kept inside the
envelope, or on stickers applied to the envelope.

Simply put, an XML-RPC service ignores most features of HTTP. It exposes
only one URI (the “endpoint”), and supports only one method on that URI (POST). e.g. No matter what you do with the UPC database service,
the URI is always http://www.upcdatabase.com/rpc and the HTTP method is always
POST.

A few well-known examples of RPC-style web services:
• All services that use XML-RPC
• Just about every SOAP service (see the “Technologies on the Programmable
Web” section later in this chapter for a defense of this controversial statement)
• A few web applications (generally poorly designed ones)

REST-RPC hybrid
The Flickr web API asks clients to use HTTP GET even when they
want to modify the data set. To delete a photo you make a GET request to a URI that
includes method=flickr.photos.delete. That’s just not what GET is for, as I’ll show in
“Split the Data Set into Resources [115]. The Flickr web API is a REST-RPC hybrid:
RESTful when the client is retrieving data through GET, RPC-style when the client is
modifying the data set.

A few well-known examples of REST-RPC hybrid services include:
• The del.icio.us API
• The “REST” Flickr web API
• Many other allegedly RESTful web services
• Most web applications

Why singleton is bad

- Against the OO spirit and increase coupling which usually becomes hidden

- Classic Singleton approach is hard to unit test

- Classic Singleton Class is hard to be inherited

http://code.google.com/p/google-singleton-detector/wiki/WhySingletonsAreControversial

http://stackoverflow.com/questions/1020312/are-singletons-really-that-bad

http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/

http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/

http://sites.google.com/site/steveyegge2/singleton-considered-stupid

J2SE v.s. J2EE

http://www.velocityreviews.com/forums/t141428-j2ee-vs-j2se-vs-jdk.html

J2SE - Java 2 Standard Edition. This is what most people need for a
Servlet/Beans/JSP/XML/JDBC web application or Swing desktop application.

J2EE - Java 2 Enterprise Edition. This is J2SE plus RMI tools, EJB, an
EJB server, and other distributed computing tools. There's a high
development overhead to using J2EE features so don't bother unless you
need them.

http://stackoverflow.com/questions/402056/should-i-do-more-javase-before-jumping-to-javaee

Why stateless utility class with static methods is bad?

- Violation of the OO design principle:
---- Theoretically, if such a static method takes in arg1, arg2, ... and change their 'state', then either:
--------1. arg1, arg2, should be members of a separate class Class1 and assigned through constructor 
--------2. the operation carried out by this static method should be part of classes of arg1, arg2 ....

- Hard to mock and Unit Test

Practically, however, most people don't ban it in entirety.

+ Could potentially save memory in multithread operation (the Utility object itself is read-only by the thread as it contains no state, hence no race or deadlock) - e.g. Stateless session bean pool in J2EE?

+ Examples of existing implementation:

JAVA 

java.lang.Math

java.util.Collection

C#

System.Collections.Specialized.CollectionsUtil 

System.Net.WebUtility

http://stackoverflow.com/questions/3339929/if-a-utilities-class-is-evil-where-do-i-put-my-generic-code

http://stackoverflow.com/questions/3340032/utility-classes-are-evil

http://stackoverflow.com/questions/1942903/java-class-with-only-static-fields-and-methods-bad-or-good-practice 

How To Design A Good API and Why it Matters

http://www.youtube.com/watch?v=aAb7hSCtvGw