On first sight, the architectural style of REST via HTTP seems to constrain us to simple CRUD APIs: We operate on „resources“ which we often map rather exactly to our internal domain- / entity-types and we also mainly use the HTTP-Verbs GET (=retrieve), POST = (=Create + Update partly), PUT (=Update/Replace) and DELETE. But how can this fit if we need to implement some kind of business logic like validation, that is not directly related to one of the CRUD-operations? I want to show you a real life example and explain how I solved the problem.
In this first part of my upcoming series I’d like to show you a new way of implementing the “factory-method” pattern. To be more precise, it is what the famous “Gang-of-Four” call a “parameterized factory-method” in the Design Patterns-Book (see the “Implementation” section of the “Factory Method Pattern” on page 110/111). For simplicity I will use the term “factory-method” synonym to “parameterized factory-method”. The crucial point here will be, that the factory no longer needs any compile-time dependencies upon any concrete interface implementation. Furthermore I will explain how to write un-mocked unit-tests for a CDI-Bean (the factory) in order to be able to check that all the CDI annotations work as desired without having to start an application server.