Flooding API Design
1. Introduction
2. API Architecture and Design
2.1 Overview
- Backend Framework: Python Django
- Database Storage Options:
- SQLite
- Azure Table and Blob Storage
2.2 Required Features and Functionality
- Site/Location management via CRUD.
- Eventual support for users?
- Shapefile management via CRUD (no Update, just CRD)
- HDF Results management via CRUD (no Update, just CRD)
3. Database Design
- Site/Location
- Name
- Longitude
- Latitude
- Default Flood Level
- Default Flood Area/Size
- Shapefile
- HDF Results (as File or Timeseries?)
4. Option Analysis: Database Storage
4.1 SQLite
- Advantages
- Lightweight
- Simple
- Free
- Disadvantages
- Potentially difficult implementation in the cloud, i.e. when API is an Azure Web Service.
- No remote connections
4.2 Azure Table and Blob Storage
- Advantages
- Simpler implementation in Azure than SQLite
- Storing files (i.e. Shapefiles and HDF files) in blobs is technically easier than the alternative of storing in file system with paths stored in SQL
- No local files to worry about managing/transferring (i.e. db3)
- Disadvantages
- An extra cost
- Potentially slower due to cross-network communication
- Unknown difficulty in implementing Azure API calls from Python
4.3 Hybrid Implementation (SQLite + Azure Blob)
Preferred
Files stored in Azure Blobs
Other tables stored in SQLite (Users, Scenarios, etc.)
Store path to files (Shapefile/HDF) in SQL, similar to file system pointer.
5. Authentication
Authentication is implemented with the third-pary django-rest-knox package. This is suggested as a replacement for DRF's default token implementation.