Challenge Overview
Project Overview
The customer is a company that does crowdsourcing challenges similar to topcoder, but has their own ways of doing things. They want to create a web application which will allow their customers to write their own challenges.
Competition Task Overview
This challenge should design the API for this project.
Note: Please use Swagger (http://swagger.io/) to design the API for this project. You should provide the Swagger API Design and developer will use the Swagger API Design to generate the Spring MVC API implementation.
The UI Prototype and ERD will be provided to registrants.
Detailed Requirements
- This project should be a separate war module.
- 'Publishing' the challenge is when the challenge is actually inserted into the our system, and this is done via the rest challenge/create API. Up until this point, the proto-challenge is not stored as a challenge in our database. (We can create new tables in the database, but they should be logically distinct from what is there.)
- Here is the mapping to use between the draft/pending challenges and our database challenge:
The provided ERD only covers a part of tables and this challenge need to design the new tables.
VIEW: DATABASE:
Title title
Startdate posted_date
End date deadline
Brief summary brief
Overview overview
Background challenge_background
problem statement description
judging criteria criteria
deliverable criteria deliverable_criteria
challenge image image_filename
tags challenge_tags
attachments challenge_attachments
agreements challenge_agreements
2. This project should use an API provided by client for authentication and authorization. The API is deployed here: http://54.164.41.194:8080/ar/api and you can also find the source code and steps in attachment.
3. This project could use Madcap for the help artifacts (good, bad examples, context sensitive help for fields, tutorials and documents).
If you feel it's not easy or good to integrate with Madcap, we can also define the APIs for help artifcats, desiare stored in a database or in a file system. However, they must be accessible via some mechanism- such as a key-- to support context sensitivity. It must also be straightforward (and quick) to update them when needed.
4. Agreements and tags are interesting. They are currently stored in our database and would change over time. So they should not be hard-coded in this module. Please provide simple rest services that could be used to populate these items on application startup. There are no challenge_disciplines, only tags. So the challenge discipline in the view should be left out.
5. We do not store any file attachments in the database. They are stored on an encrypted file system, and can not be accessed directly. The file name and handle for access is stored in the database. We will reuse the encrypted file system of existing site.
6. it occurs to us that we are going to need to put in some sort of multi-tenance capability into the self-serve ideation. Once the challenges get to our website, they are visible for all solvers to see. But within the self-serve ideation module I am sure only registered users from that company should be viewing them. We've included the key tables we use for AtWork's multi-tenant capability as well. (The tables are not much, but their will need to be access control code to manage it.
Open Source Library
Swagger
Technology Overview
Swagger
Final Submission Guidelines
- Application Design Specification
- Assembly Challenges Specification
- Swagger API Design
- ERD