SpringMVC and Dubbo both support REST services, so how do we choose to develop a REST service interface? This paper will include the following two aspects:

  1. REST service writing
  2. Application scenarios of REST services

1. REST service writing

Let’s first look at how SpringMVC implements a REST service:

@RestController
@RequestMapping("/greetings")
public class SpringRestController {

    @RequestMapping(method = RequestMethod.GET,
                    value = "/{name}", 
                    produces = MediaType.TEXT_PLAIN_VALUE)
    publicResponseEntity<? > greeting(@PathVariable String name) {
        String greeting = "Hello " + name;
        return newResponseEntity<>(greeting, HttpStatus.OK); }}Copy the code

Those of you who have used SpringMVC will be familiar with these annotations: @restController, @RequestMapping, @pathVariable.

Before we look at how Dubbo implements REST services, let’s take a quick look at Dubbo’s REST history. Dubbo opened source in 2011 and stalled in 2014. Earlier Dubbo did not support REST, but if you want to implement a REST service, there is a way to use SpringMVC to call Dubbo’s service in Controller. But what if REST is so popular that you want to support REST directly on Dubbo? In 2014, Dangdang forked a version of Dubbo to start maintenance, named DubboX, and added reST-style remote calls. Later, with the merger of Dubbo and DubboX, Dubbo incorporated REST support in DubboX.

With this framework history behind us, let’s take a look at how Dubbo implements REST services:

@Path("/greetings")
public class DubboService {

    @GET
    @Path("/{name}")
    @Produces(MediaType.TEXT_PLAIN)
    public Response greeting(@PathParam("name") String name) {
        String greeting = "Hello " + name;
        returnResponse.ok(greeting).build(); }}Copy the code

You can see that Dubbo uses different annotations than SpringMVC, @path, @get, and @PathParam. This set of annotations is defined by the JAX-RS specification. Regarding jax-rs, which is the standard Java REST API, specific open source implementations include Oracle Jersey, RedHat RestEasy, Apache CXF and Wink, and Restlet, among others. Dubbo uses RestEasy to support REST services.

Since Java REST already has a jax-rs standard, why doesn’t SpringMVC use it? I guess the main reason is that SpringMVC already has its own annotations, such as @RequestMapping, which was used before REST, so consider using the original annotation style when supporting REST.

2. Application scenarios of REST services

The differences between SpringMVC and Dubbo are described in Section 1. How to choose according to the application scenario. Let’s start by looking at some REST application scenarios for Dubbo:

  1. Calls (across languages) between heterogeneous systems within an enterprise. Dubbo’s system serves as the service provider, and systems in other languages (including some Non-Dubbo Java systems) serve as the service consumer, communicating via HTTP and text messages. Even compared to binary cross-language invocation schemes such as Thrift and ProtoBuf, REST has its own unique advantages.
  2. Open API (Open platform) development. You can use Dubbo to develop specialized Open API applications, or you can directly “transparently” publish the Dubbo Service for internal use to the external Open REST API.
  3. Simplify mobile (tablet) APP or PC desktop client development. Similar to point 2, Dubbo can either be used to develop a wireless or desktop server, or the internal Dubbo Service can be directly “transparently” exposed to mobile apps or desktop applications.
  4. Simplify AJAX application development for browsers. Similar to point 2, you can either use Dubbo to develop a dedicated AJAX server, or you can directly “transparently” expose the internal Dubbo Service to JavaScript in the browser. Of course, many AJAX applications are better suited to working with Web frameworks, so direct access to Dubbo Service may not be a very elegant architecture for many Web projects.
  5. Provides a text-based, easy-to-read way to make remote calls between Dubbo systems within an enterprise, where both the service provider and the consumer are Dubbo based systems.
  6. To some extent, it simplifies Dubbo system to call other heterogeneous systems. REST services provided by non-Dubbo systems (whether the service provider is inside or outside the enterprise) can be invoked “transparently” in an easy dubbo-like manner. This is an updated version of Point 1.

Points 1, 2, and 3 are considered the three most valuable application scenarios for Dubbo’s REST services, providing REST services to non-Dubbo (heterogeneous) consumers.

SpringMVC, on the other hand, is better suited to REST services for Web applications, such as AJAX calls in Point 3. This is also in line with the CONCEPT of MVC, where REST services are an implementation of the View layer.

Jax-rs Dubbo is better suited for purely servized applications, publishing beans such as Services as REST services.

My opinion is that if you are a single Web oriented application, you should use SpringMVC without considering Dubbo. If it is a microservice application that uses Dubbo as the RPC framework and needs to be Web oriented, then it should use Dubbo to publish the service in REST mode. There is no need to introduce SpringMVC for REST, which is too complicated. And the effect is the same.

Reference 3.

  1. Developing RESTful Remoting in Dubbo
  2. Difference between JAX-RS and Spring Rest