From e1776e4cbf0106f00a11f46ed7e9ad5d543d5406 Mon Sep 17 00:00:00 2001 From: Teyras Date: Wed, 23 Nov 2016 20:30:08 +0100 Subject: [PATCH] update --- Overall-architecture.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Overall-architecture.md b/Overall-architecture.md index 1b68954..6ef5c52 100644 --- a/Overall-architecture.md +++ b/Overall-architecture.md @@ -135,7 +135,8 @@ available file servers in its config file. File server has its own internal directory structure, where all the files are stored. It provides simple REST API to get them or create new ones. File server does not provide authentication or secured connection by itself, but it is supposed to run file server as WSGI script inside a web server (like Apache) with proper configuration. Relevant commands for communication with workers: - **GET /submission_archives/\.\** -- gets an archive with submitted source code and corresponding configuration of this job evaluation -- **GET /tasks/\** -- gets a file, common usage is for input files or reference result files +- **GET /exercises/\** -- gets a file, common usage is for input files or + reference result files - **PUT /results/\.\** -- upload archive with evaluation results under specified name (should be same _id_ as name of submission archive). On successful upload returns JSON `{ "result": "OK" }` as body of returned page. If not specified otherwise, `zip` format of archives is used. Symbol `/` in API description is root of file server's domain. If the domain is for example `fs.recodex.org` with SSL support, getting input file for one task could look as GET request to `https://fs.recodex.org/tasks/8b31e12787bdae1b5766ebb8534b0adc10a1c34c`.