Topcoder Arena 3.0 - Write swagger spec for SRM problem fetching API

Challenge Objectives

Design the API for fetching and listing the SRM problems, and fetching the details of each problem.

Project Background

Topcoder Arena 3.0 is the next generation Topcoder Competition Arena, which will be built with new and modern technologies. It will replace the legacy Topcoder Arena built by Java applet in 2001. The legacy Topcoder Arena is outdated and has some compatibility issues with modern operating systems. In Topcoder Arena 3.0, both front-end and back-end will be redesigned and rebuilt completely.

Technology Stack

• Swagger

Individual requirements

In this challenge, we are looking for you to design the following two API endpoints:

• Fetch and list all the SRM problems.

• Fetch the details of each SRM problem.

 

Here are the ERD of the existing data models. In this challenge, we only focus on the problem and component table.

 

problem is an SRM problem, component includes the details of the problem, like the problem statement, required method name, class name etc. 

 

Here are the detailed description of each field.

(1) problem

• problem_id: The unique ID of the problem

• name: The name of the program.

• status_id: The problem status ID

• program_text: (ignore it now, useless)

• modify_date: The last modify date of this problem.

• proposed_division_id: The proposed Division ID (Division 1 or 2)

• program_type_id: The program type ID

• proposed_difficulty_id: The proposed difficulty ID (Difficulty level, decimal)

• create_date: The create date of this problem.

• accept_submissions: The number of accepted submissions

(2) component

• component_id: The unique ID of the component

• problem_id: The associated problem ID

• result_type_id: The result type ID (Just consider it as a decimal for now)

• method name: The required method name

• class_name: The required class name

• default_solution: The text of the default solution

• component_type_id: The component type ID.

• component_text: The statement of the problem.

• status_id: The component status ID (Just consider it as a decimal for now)

• modify_date: The last modify date of this component.

 

Here are the requirement of the two API endpoints:

• Fetch and list all the SRM problems.

  • It should be a GET method.

  • Authentication: requires the presence of a valid TC user JWT and a valid M2M token

  • Pagination should be supported.

• Fetch the details of each SRM problem.

  • It should be a GET method.

  • Authentication: requires the presence of a valid TC user JWT and a valid M2M token

Important notes

• In the swagger spec, all response codes of each API endpoint should be documented well, including 200, 400, 401, 403, 404, 500 etc, not just 200.

• For each response code, you need to provide an example.

• The swagger should follow the Topcoder V5 standard (The standard file is attached in the forum), you can take the existing Topcoder v5 API swagger for reference:

  • https://github.com/topcoder-platform/submissions-api/blob/develop/docs/swagger.yaml

  • https://github.com/topcoder-platform/tc-bus-api/blob/dev/api/swagger.yaml

Final Submission Guidelines

A well-written swagger file