-
-
Notifications
You must be signed in to change notification settings - Fork 3
Common components across all layers
Authorization and Authentication Interceptor that invokes our Authentication Micro service (This can be a pass through until we have the Authentication service developed). This interceptor will invoke calls to Authorization micro service for the following
As all the APIs are REST based, we do see deal with default request headers, custom request headers and response headers. For instance, user authorization token or session token will not be sent in the request body , but as a part of the header. Another example is Trusted app's Unique Identifier. Secondly, whether the client has access to APIs, whether the user has access to APIs, will not be handled in the business methods of these APIs but it’s the job of interceptors to validate the access and see if the request need to be forwarded to API.
Although, at this point, we are not sure of access grants for the users and clients, we should be able to read headers, authorization tokens or implement accessory methods to read custom headers that we might come up with.
- OAUTH
- Client Token (trusted app) verification
- Client API access
- User Access / Role level permissions (spring security ?)
- Session Token validation
REST APIs access service layer components. All service layer components are spring beans. However, REST layer should not be able to wire these service layer components directly but they should request the service layer components from a factory. Essentially, As all REST APIs extend / implement a base class / interface, the service factory will be wired in the base class, so any REST API we develop - the service factory is available for the API and hence any business layer component that is tied up with the factory. This is the much cleaner and efficient approach, as you don't have to wire service layer dependencies in each and every API separately.
-
- Named query execution - generic implementation
-
- Native sql Query execution - generic implementation
-
- Unique Results
-
- Stored proc execution - generic implementation
-
- Criteria query -generic implementation
As we implement our APIs, based on the business requirements, we query DB in different ways - either by sending Hibernate Criteria/ Example objects, or by sending a Native SQL, or by sending Named queries. These generic method implementations will take care of obtaining the session, creating instances of query , setting up parameters to the queries and execute the queries, and sending the result set (Persistent object array) back. So, DTOs need not worry about these implementations but just call these methods . Also, POJOs, as we know that we have metadata fields (createdat, createdby, modifiedat,modifiedby etc), are applicable for each POJOs, we should have some means, to set these values through common methods.
All the APIs define certain HTTP error codes applicable for each API. These error codes can be same for different business exceptions. For instance, 404 error code can be thrown by Enrollment service when the user is not found, and the same 404 error code can be thrown by Client service, when Client is not found in the system. A common approach has to be defined so that all these exceptions are handled at REST layer in a common way, for each Micro service.
Other than the general purpose annotations the comes out of the box, We can use annotations to assign certain attributes at various levels (class level / method level etc.). Being able to assign a Unique Identifier will facilitate us to determine where the user is coming from (You don't need to use reflection to figure which method is being run by this user , or which method throws a certain exception etc). So, based on these annotations and their defining properties you can accomplish the following.
-
Assign a unique Id (API ID) for a REST API (for example : REST_enrolloment_createAPI or REST_event_createEvent or REST_Notification_updateNotification), as use these unique values to define the Access to trusted Apps, in the Database. Essentially, the Interceptor (check above) we define can check if the client has access to this specific API ID.
-
Assign a unique Id for a specific method (Service Layer, REST Layer, DAO Layer) and use Spring AOP for Auditing or logging purposes. When the control goes to an Advice (for exception handling / logging / auditing), depending on the Unique Id, we can determine if any specific action need to be taken.
Any common utilities that we use across the board. We maintain these utility methods in our common library so, we do not duplicate the code. We don't necessarily write these utility methods before hand, but keep adding as we progress with development. Examples
- string comparisons
- JSON-XML / XML-JSON converters
- Date utilities
One common requirement from APIs is how do we send response back to the client, when you have thousands of records that match the criteria. We need to enforce clients to ask for a subset of results always and provide clients with a mechanism to come back for the subsequent results. This is a critical requirement as this impacts how the data is retrieved from DB. You see this typically in every application that we use - Amazon, eBay, Banking sites, e-mail apps, yelp etc..