SOAP x REST API

SOAP x REST API. When should I pick one of them? Why? These are questions that are always raised when you're discussing a new architecture. Sometimes you may face someone saying to get REST just because everybody uses REST. Really?

I'm not here to teach anyone to write a SOAP Web Service or a REST API. And I don't own the truth, I'm just exposing my own opinion based on my experience.

The Concept

In a simple way to understand the concept, we can assume Web Services as pieces of software running under a application server, responsible for synchronous communication.

Along with JMS, it's heavily used on systems integration. One thing that must be clear is that Web Services and SOA are not the same thing. SOA is the architecture that makes use of services. And these services can or cannot be web services. The umbrella for services on the SOA concept is wider than the single idea of a web service.

SOAP x REST API

When we talk about web services, we always gets into a discussion about SOAP Web Services versus the REST API, their differences, and when to adopt each one.

SOAP is the communication protocol that runs over HTTP that makes use of a XML document that describes the methods and parameters used by the web service. This document is known as the WSDL file, and it's basically the contract between the web service and the client.

When we read and learn about SOAP, the UDDI is always mentioned. UDDI can be seen as a catalog of web services. But I've never seen an UDDI fully implemented and in use.

The Java specification in this case is the JAX-WS - JSR 224.

On REST, instead of having a contract, you make use of URLs and verbs (GET, POST, PUT and DELETE), just like HTTP, to pass information to the client. This information doesn't have to be an XML document. Can be anything else, like a JSON document.

The Java specification in this case is the JAX-RS - JSR 339.

When to use them? Some may say it's a really abstract question, since both can solve the same problems. But you can find some differences when you think about their nature. Imagine a Bank, that needs to be integrated to external companies. The systems are exposed to their partners as web services. In this scenario, it's interesting to have a well defined document/contract for the communication, to make sure the correct information is being sent/received. I believe that's the reason SOAP the most used protocol on the integration scenarios. Even though you can use REST with a XML being communicated and validated agains an XSD, for example, on SOAP, this contract is more consistent.

In another hand, for a product developed by one company, exposed over the internet, it will make calls to their own systems. Lighter and with higher performance, REST looks like to be the best option on this scenario.

Some Testing Tools

soapUI
cURL

Mockito and PowerMock together to mock static methods

 Probably this happened to you before. You come into a project, and you have to mock a static method. In this particular project, Mockito is the framework used, and the idea to have another one in place is unacceptable. You are just told to change your class, and instantiate it when necessary. Problem solved... really? I don't think so.

Behind that there's that old discussion about the usage of static methods against the principals of object orientation. This is another long discussion. In my humble opinion, static methods are really useful in some scenarios, like utility classes. Also, just remember Singleton... Well I'd better stop here with this topic. Let's get back to the mocking issue.

So, Mockito doesn't cover the static methods, but that's the one used in your project. So, why not make use the PowerMock just for the static methods? Yes, Mockito and PowerMock can be used together. You don't need to look at two distinct frameworks, you will be combining them. So, basically, PowerMock provides a class called PowerMockito to handle that. For everything else, you just use Mockito.

And it's pretty easy! I wrote a really simple test to prove it. First, these are my dependencies on Maven:

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>4.8.2</version>

      <scope>test</scope>

    </dependency>

    <dependency>

      <groupId>org.mockito</groupId>

      <artifactId>mockito-all</artifactId>

      <version>1.9.5</version>

    </dependency>

    <dependency>

      <groupId>org.powermock</groupId>

      <artifactId>powermock-module-junit4</artifactId>

      <version>1.5.4</version>

      <scope>test</scope>

    </dependency>

    <dependency>

      <groupId>org.powermock</groupId>

      <artifactId>powermock-api-mockito</artifactId>

      <version>1.5.4</version>

      <scope>test</scope>

    </dependency>

Note I have both frameworks, and the PowerMock API to Mockito.

Your JUnit class test will need two annotations:

@RunWith(PowerMockRunner.class)@PrepareForTest(YourClass.class)

You'll have to define on the setUp method the results from the static method with given arguments:

@Before public void setUp() {

      app = new App();

 

      PowerMockito.mockStatic(YourClass.class);

      PowerMockito.when(YourClass.isBlank(null)).thenReturn(true);

      PowerMockito.when(YourClass.isBlank("")).thenReturn(true);

      PowerMockito.when(YourClass.isBlank("X")).thenReturn(false);

  }

Finally, you write you test:

  public void testDoSomething() {

      assertEquals("X", app.doSomething("X"));

      assertEquals("No arguments!", app.doSomething(null)); 

  }

My test on GitHub