Testing classes in isolation and with mocks is popular. But those tests have drawbacks like painful refactorings and the untested integration of the real objects. Fortunately, it’s easy to write integration tests that hit all layers. This way, we are finally testing the behavior instead of the implementation. This post covers concrete code snippets, performance tips and technologies like Spring, JUnit5, Testcontainers, MockWebServer, and AssertJ for easily writing integration tests. Let’s discover integration tests as the sweet spot of testing.

The term Microservices is quite vague as it leaves many questions unanswered. Contrarily, a Self-Contained Systems subsumes concrete recommendations and best practices that can guide you to create an application which is resilient and independent. But how can we implement such a system? At Spreadshirt, we build an application following the recommendations of a Self-Contained System. In this post, I’ll show you which technologies we used and which challenges we faced.

In the last post, I presented the Timestamp_Offset_Checkum continuation token for implementing web API pagination. After using them in practice for a while we discovered some drawbacks and finally came up with a new approach: Timestamp_ID. This approach is fast, scalable, efficient, stateless and easy to implement. Our pursuit of the best pagination strategy has finally come to an end.

Implementing proper pagination for Web APIs is not trivial. Offering limit and offset query parameters doesn’t cut it because this approach is slow and error-prone. But also keyset paginations with parameters like modified_since have drawbacks. Fortunately, there is a better approach: Continuation Tokens (aka Cursors). They provide fast, reliable and stateless pagination and make the client implementation very straight-forward. In this post, I propose the Timestamp_Offset_Checksum continuation token, the algorithm and point to a library simplifying its implementation.

Writing documentation manually for a RESTful API can be laborious. On the other hand, relying exclusively on the generation of the documentation (e.g. with swagger-ui) is often not sufficient. There are always aspects (like common use cases and workflows) that need to be described manually. Let’s see how we can combine these two approaches with the help of AsciiDoc!

Testing RESTful Web Services can be cumbersome because you have to deal with low-level concerns which can make your tests verbose, hard to read and to maintain. Fortunately, there are libraries and best practices helping you to keep your integration tests concise, clean, decoupled and maintainable. This post covers those best practices.

Consuming RESTful services can be a laborious task, because there is much low-level-work to do. Jealously we looked at the WS*/SOAP guys: They can easily generate a nice client API based on the formal interface specification WSDL. This significantly simplifies the service consumption. For a long time the REST world lacks a widespread formal specification and generation tools. But Swagger sets out to change this.

Designing HTTP and RESTful APIs can be tricky as there is no official and enforced standard. Basically, there are many ways of implementing an API but some of them have proven in practice and are widley adopted. This post covers best practices for building HTTP and RESTful APIs. We’ll talk about URL structure, HTTP methods, creating and updating resources, designing relationships, payload formats, pagination, versioning and many more.