0

I'm implementing a series of REST micro services in Java - let's call them "adapters".

Every service reads the data from a particular source type, and provides result in the same way. The main idea is to have the same interface (service contract) for all of them, to get interchangeability. I would like to avoid code duplication and reuse the service contract for the services.

And it seems that I'm reinventing the wheel. Is there a standard approach for this?

I tried to extract the service contract in form of Java interface for Spring MVC Controller class and accompanying DAO class CustomObject:

public interface AdapterController {

    @RequestMapping(method = RequestMethod.GET, value = "/objects/{name}")
    CustomObject getObject(@PathVariable final String name);

}

Then put them into separate Maven project, set it as a dependency in the original project, and rewrote REST controller class as following:

@RestController
public class DdAdapterController implements AdapterController {

    @Override
    public CustomObject getObject(String name) {
        return model.getByName(name);
    }

I can reuse DAO object in a client code as well, but the interface class is useless at client side.

1) Summarizing: is it OK to reuse/share service contract between different service implementations? What's the cost of this? Is there the best practice how to share service contract?

2) The next question is about service contract and consuming client. Is it OK to share the contract between service and client? Is there some tools in Java / approach for this?

Alexander Sorkin
  • 634
  • 7
  • 20

2 Answers2

1

This goes against the microservice mentality and in the long run is a bad idea to share code.

If you start sharing code you will slowly just build a distributed monolith, where multiple services are dependent on each other.

Many have talked about this earlier:

microservices-dont-create-shared-libraries

The evils of too much coupling between services are far worse than the problems caused by code duplication

Micro services: shared library vs code duplication

The key to build microservices is:

  • One service should be very good at one thing
  • Keep them small
  • Have an extremely well documented api
  • When you need to delete a microservice this should be done with as few needs to update other services
  • Avoid code sharing, and treat all libraries like 3rd party libraries even your own
Toerktumlare
  • 12,548
  • 3
  • 35
  • 54
  • Thanks for the links! I could not see that shared interface - is just a special case of shared library. The best way to check service contract - check it outside. As other clients would do. [There are a lot of tools in Java for that](https://phauer.com/2016/testing-restful-services-java-best-practices/). – Alexander Sorkin Feb 19 '19 at 09:27
0
  1. Microservises should by loosely coupled = minimum dependencies.

    Microservices is an architectural style that structures an application as a collection of services that are

    • Highly maintainable and testable
    • Loosely coupled
    • Independently deployable
    • Organized around business capabilities.

https://microservices.io/

Contract can be defined with WADL

  1. Using contract between client and server means less bugs, less missunderstandings when implementing client. That is what the contract good for.
Peter Šály
  • 2,848
  • 2
  • 12
  • 26
  • Thanks for the WADL link! --- May be I was not enough clear - I need several different implementations of one service's type. They all should have the same service contract and will be maintained/deployed by the same team. The services under discussion will not interact with each other, they should interact with consuming services only. --- I totally agree, that contract helps to minimize bugs. The question is what's the proper way to check if the service/client fulfills the contract. – Alexander Sorkin Feb 18 '19 at 21:19