|
| 1 | +API for ContestWebServer |
| 2 | +************************ |
| 3 | + |
| 4 | +Error handling |
| 5 | +============== |
| 6 | + |
| 7 | +Generally, API calls will return a non-200 status code on invalid usage. In |
| 8 | +that case, the body of the response *may* be a JSON object with an "error" |
| 9 | +field, containing additional information on the error. |
| 10 | + |
| 11 | +Authentication |
| 12 | +============== |
| 13 | + |
| 14 | +All the log-in methods and restrictions that apply to normal ContestWebServer |
| 15 | +usage also apply for API usage. In particular, this implies that IP autologin, |
| 16 | +if configured, can be used for API calls. |
| 17 | + |
| 18 | +Otherwise, making a `POST` request to the `/api/login` endpoint, passing |
| 19 | +`username` and `password` as form data (as is done for regular login), will |
| 20 | +return a JSON object with the following structure: |
| 21 | + |
| 22 | +.. sourcecode:: json |
| 23 | + |
| 24 | + {"login_data": string} |
| 25 | + |
| 26 | +The content of the returned login data string should be passed to API calls |
| 27 | +that require authentication in a `X-CMS-Authorization` header. |
| 28 | + |
| 29 | +All other API methods described here require authentication. |
| 30 | + |
| 31 | +Task list |
| 32 | +========= |
| 33 | + |
| 34 | +An authenticated `GET` request to `/api/task_list`, done while the contest is |
| 35 | +running, will return the following object: |
| 36 | + |
| 37 | +.. sourcecode:: json |
| 38 | + |
| 39 | + {"tasks": [{"name": string, "statements": [string], "submission_format": [string] }]} |
| 40 | + |
| 41 | + |
| 42 | +Tasks are ordered in the same order as in the UI. The `name` of the task is |
| 43 | +used for additional task-specific API calls. `statements` contains a list of |
| 44 | +languages for which a statement is available. `submission_format` contains a |
| 45 | +list of files that will need to be submitted, where filenames containing the |
| 46 | +`%l` string represent source files (that will be compiled and run on the |
| 47 | +server), and all other filenames represent output files. |
| 48 | + |
| 49 | +Submit |
| 50 | +====== |
| 51 | + |
| 52 | +An authenticated `POST` request to `/api/{taskname}/submit` will send a |
| 53 | +submission. Files should be provided (according to the submission format) as |
| 54 | +form data, with field names matching the submission format. |
| 55 | + |
| 56 | +The request will return an object with the ID of the new submission: |
| 57 | + |
| 58 | +.. sourcecode:: json |
| 59 | + |
| 60 | + {"id": string} |
| 61 | + |
| 62 | + |
| 63 | +List submissions |
| 64 | +================ |
| 65 | + |
| 66 | +An authenticated `GET` request to `/api/{taskname}/submission_list` will return |
| 67 | +an object describing all the submission done so far on the given task, in |
| 68 | +chronological order: |
| 69 | + |
| 70 | +.. sourcecode:: json |
| 71 | + |
| 72 | + {"list": [{"id": string}]} |
| 73 | + |
| 74 | +Task statement |
| 75 | +============== |
| 76 | + |
| 77 | +A PDF version of the task statement for a given language can be retrieved by |
| 78 | +making an authenticated `GET` request to `tasks/{taskname}/statements/{lang}`. |
| 79 | + |
| 80 | +Scoring information |
| 81 | +=================== |
| 82 | + |
| 83 | +An authenticated `GET` request to `/tasks/{taskname}/submissions/{id}` will |
| 84 | +retrieve information on the submission with the given `id`. In particular, |
| 85 | +its field `public_score` will contain the score of this submission, and |
| 86 | +`task_public_score` will contain the current score for the task. |
| 87 | + |
| 88 | +Additional details on the submission's results can be retrieved by making an |
| 89 | +authenticated `GET` request to `/tasks/{taskname}/submissions/{id}/details`. |
| 90 | +The endpoint will return an HTML snippet matching what is seen by contestants. |
0 commit comments