Challenge Overview
In this challenge series we are looking to develop a file service - a reusable service where a Source system can upload a file using http(s) and in return gets a technical handle (URL). The Technical handle is transmitted via Integration to the Destination which can use the handle to download the file. Service will have a security model that will allow uploader to set access permissions for the uploaded file. Destination services will have the option to register for webhook events for new files.
Here is a system diagram:
In a previous challenge we have defined service architecture. High level of endpoints supported by the service (/v1/fileservice/ path prefix)
Service architecture is posted in the forums. Two changes should be made to the architecture:
Change download endpoint to return multipart response instead of json encoded payload
Add a path attribute to the FileInfo structure to point to the saved file in the local filesystem (files are kept in the local filesystem, but when number of files reaches 1000, files are stored in a different subfolder).
Non functional requirements for the service are:
Submit a short deployment/verification guide
Submit a postman collection for manual testing
Here is a system diagram:
In a previous challenge we have defined service architecture. High level of endpoints supported by the service (/v1/fileservice/ path prefix)
- /integrations – Manage integrations and systems within each integration
- /auth – Authentication – gives JWT bearer tokens
- /files – file uploads and downloads
- /eventListeners – Event management api (registering for webhook callbacks)
- /auditRecords – audit logs
Service architecture is posted in the forums. Two changes should be made to the architecture:
Change download endpoint to return multipart response instead of json encoded payload
Add a path attribute to the FileInfo structure to point to the saved file in the local filesystem (files are kept in the local filesystem, but when number of files reaches 1000, files are stored in a different subfolder).
Non functional requirements for the service are:
- Filesize shall only be limited by underlying file-storage system
- Md5checksums shall be calculated at file upload
- Md5Checksums shall be compared if provided at upload
- File retention (days it should be kept) can be set by source system at upload, but can never exceed x days
- Filenames stored on underlying MUST be decoupled from source filenames (i.e. technically generated)
- If file-system is used for file-storage, the folders MUST not contain more than 1000 files per folder ( Linux folder operations becomes slower and slower if NFS shared folders contain more than 1000 files )
Final Submission Guidelines
Submit the full source codeSubmit a short deployment/verification guide
Submit a postman collection for manual testing