OData REST API Layer - System Architecture

Project Overview

The OData project is going to develop a powerful API layer (with a robust data model) which will be used to provision select business data.
 The main purpose is twofold:

1. Create an OData (version 4+) compliant REST APIs to allow access to the specified data.
2. The code for the services must be generated (and potentially re-generated) via template-driven code generators.

Currently the client is using SOAP based APIs that are antiquated and cumbersome; what the client needs is flexible data APIs that can handle the needs required for modern applications and consumers.  
The client wants to use Representational State Transfer (REST) as this is the architectural style suited for these modern applications and purposes.

Your task will be to investigate the client requirements (See the attached document in the forums) and provide a System Architecture which would outline the full architectural approach (and which would stipulate a POC as well as 1-2 assemblies) in a manner that we can ensure predictable maintenance and easy to utilize technology stack.

NOTE: please make sure that you read the client docuemnt which has been attached in the competition arena. It already has a lot of architectural details which you will incorporate in your submission.

The basic requirements are as follows (but more details are provided with attached document):

1. General Workflow Overview
   1. Create an OData (version 4 or greater) compliant REST APIs.  All APIs will be read only. APIs must support all the standard OData query constructs. 
   2. Code must be generated using code generators. The client's preference is to use T4 template but is open to other popular open source solutions like Yeoman. Note that adding new tables should not in any way cascade into extra coding. Users should be able to describe any necessary connectivity, indexing details, etc...  in a template and then generate the Service API code automatically.
   3. Code should generate Swagger compliant documentation/WADL with the use of Swashbuckle. Templates should generate the code with required dependencies and attribute decoration.
   4. Code must be reusable and readable. It must be built on good design patterns. Code must follow Microsoft coding standards.
   5. All incoming requests should be intercepted in the generated services to check some specific input value (check if there is a $top value provided) and this should be configurable.
   6. Industry best practices for REST should be followed to return errors. i.e. service must not return 200 if there was an error.
2. UI
   1. The generator will not be utilizing any custom UI.
3. Security 
   1. Authorization and security are not a concern for this project. Challengers should use best practices of course, but the client has their own methodology for authentication for the services that they will implement.

Competition Task Overview

Your task will be to look through the provided requirements document (RESTDataServicesTechnicalSpecificationv1.1.docx) as well as client provided source code and address the approach to the templatization process.. This would be in the form of a specification as well as UML class diagrams which would follow established design patterns.  Note that the main concern here is a good detail of how the templatization process should be implemented.

Client Source code considerations:

Note that the client source code has also been added/attached to the requirements document for you to consider.

Please looks specifically at the Global.asax.cs code and see the comments provided within for what the client is thinking in terms of the approach. Make sure to ask any questions you might have early.

POC:

Create a POC contest specification which would showcase the coded approach to the templatization process and show the full utilization of the technology. The reasoning is to quickly show full utilization of the technology stack. Note that a proof of concept is a simple and easy to developed solution that shows the viability of the approach so as catch any issues with development early in the cycle. Such a POC contest specification must be included in your architecture.

Assemblies:

Please create 1-2 assmenbly specifications to address the full solution. You can create a main assmbely to be followed up with a simpler additional assmebly to clean things up.

Platform Requirements:

1. .Net 4.6 and Web API frameworks should be used to build the APIs
2. Data Access Layer should be built with Entity Framework 6.
3. Entities will be POCOs
4. C#
5. OData ver. 4+
6. T4 template (Entity Framework
7. REST
8. JSON
9. Code must have proper level of logging in place.

Additionally the following will be utilized:

1. Moq
2. Swagger
3. Swashbuckle
4. Visual Studio 2015 would be the choice of IDE.
5. NuGet should be used to manage the dependencies for the API project

Final Submission Guidelines

Submission Deliverables

1. System Design Specification (SDS) document written in an MS Word compatible document
2. Class and sequence diagrams authored using the TopCoder UML tool. (These will be utilized in assmebly competitions)
3. Downstream competitions specifications (POC, Proposed Assemblies, Integration Assembly) - see points 4 and 5 below.
4. POC contest specification
5. 1 or 2 Assembly competitions (post POC) which would implement the full solution in a well documented and tested code. 
6. NOTE: Game plan is *not* required.