JarCasting
JarCasting JarCasting

one.xingyi:rest2test

A library to allow Restful APIs to be easily written

License

License
GroupId

GroupId

one.xingyi
ArtifactId

ArtifactId

rest2test
Last Version

Last Version

1.1
Release Date

Release Date
Type

Type

jar
Description

Description

A library to allow Restful APIs to be easily written

Download rest2test

Filename Size
rest2test-1.1.pom
rest2test-1.1.jar 28 KB
rest2test-1.1-tests.jar 57 KB
rest2test-1.1-sources.jar 20 KB
rest2test-1.1-javadoc.jar 529 KB
Browse

How to add to project

<!-- https://jarcasting.com/artifacts/one.xingyi/rest2test/ -->
<dependency>
    <groupId>one.xingyi</groupId>
    <artifactId>rest2test</artifactId>
    <version>1.1</version>
</dependency>
// https://jarcasting.com/artifacts/one.xingyi/rest2test/
implementation 'one.xingyi:rest2test:1.1'
// https://jarcasting.com/artifacts/one.xingyi/rest2test/
implementation ("one.xingyi:rest2test:1.1")
'one.xingyi:rest2test:jar:1.1'
<dependency org="one.xingyi" name="rest2test" rev="1.1">
  <artifact name="rest2test" type="jar" />
</dependency>
@Grapes(
@Grab(group='one.xingyi', module='rest2test', version='1.1')
)
libraryDependencies += "one.xingyi" % "rest2test" % "1.1"
[one.xingyi/rest2test "1.1"]

Dependencies

compile (1)

Group / Artifact Type Version
one.xingyi : core jar 1.1

provided (1)

Group / Artifact Type Version
org.projectlombok : lombok jar 1.18.4

test (5)

Group / Artifact Type Version
one.xingyi : reference3 jar 1.1
one.xingyi : democlient jar 1.1
one.xingyi : reference3 test-jar 1.1
junit : junit jar 4.12
org.mockito : mockito-all jar 1.10.19

Project Modules

There are no modules declared in this project.

This is an evolution of two earlier attempts at the same idea.

This project is an exploratory project

It is a 'proof of concept' and not production ready code. It is written 'as fast as possible' to allow a new idea to be tested and cuts and pastes from a lot of places.

This project probably won't be maintained: like all good 'quest' or 'spike' projects it should be thrown away and the learning used to make production code

Getting going

  • Clone this project
  • Run mvn install from the project root directory

This should download all the dependancies (not many). If it doesn't compile, please contact me!

Presentations

That presentation is currently about the scala version. The ideas are the same

Goals

Reduce Coupling between microservices

This is the primary goal. Currently most microservices I see are actually RPC and the network of Microservices are a monolith. This is because they communicate using a schema.

The schema holds a lot of things. It holds the description of 'this is the data you want' which but it also holds 'here is the data you are not interested in' and 'this is the exact layout of the data'.

Easy to change with a Schema

  • Add a new attribute
  • Add a new object

Hard to change with a schema

  • Rename an attribute
  • Rename an object
  • Move attributes into a child object
  • Change a single object into a list
  • Change a list into a single object
  • Change data representation (JSON/XML/SOAP/xData/funkyData)

This project makes all of the above easy to change. All the changes are at the server and deployed clients don't need to be rebuilt, recompiled or even redeployed.

It isn't a perfect solution, but it makes at least 90% of the common changes trivial.

Boost runtime performance

In many (perhaps most) services, data is requested from a client and the client gives 'here is everything'. It is of course possible to provide filters in an adhoc way, and to provide multiple representations (schemas) of the data with content types, but this is usually adhoc and hard to maintain

This approach encourages the server to tell the client what it needs, and the server is able to (without work from the developers) optimise the data it sends.

This hasn't been implemented yet, but the approach supports it: the intention is to have the server accessed through interfaces, and the capabilities required by those interfaces sent to the backend using the accept header. (Most of this is implemented) the backend can then use that knowledge (handled by the library not manually) to optimise the sent data.

Boost developer performance

Currently developers spend a lot of time trying not to change the data representation and managing the lifecycle of things they do change. For example when a field is renamed the old field is kept for a while, and then eventually deleted. They worry about the impact of change of their data structures ('will they break their client'). They spend time and effort coding up the requests to the client and processing the responses

If there are a hundred clients to a microservice, each will need to code up 'how to call', 'how to get my data', and perhaps 'how to change the data'. In this project almost all of the work is handled by the server (once) and servers program against interfaces in maven/artifactory who are implemented by the server. (but in a very very losely coupled way: this is the 'secret sauce' of this project)

Remove the need for contract tests

While I am very enthusiastic about contract tests for microservices (I generally hold it to be true that if you aren't doing them, you are doing it wrong) this project mostly negates the need for them. It basically 'shift left's the problem they are designed to solve moving a lot of the work down to the compiler / library designers, and moving the responsibility of verifying that the interfaces work to the server team (who only need to do it once not once per client)

It is of course necessary to have smoke tests, but these are much fewer in number than the contract tests.

Versions

Version
1.1
1.0