update readme and add in API documentation

README.md

@@ -16,20 +16,19 @@ This aims to be a feature complete, production ready replacement.
 
 ## Requirements
 
-- [ ] A Computer
+- [x] A Computer
 - [ ] The ability to install rust packages
 - [ ] The ability to compile rust packages
-- [ ] A little bit of your time.
+- [x] A little bit of your time.
 
 ## Installation
 
 ### Test Deployment (or for tiny, TINY usecases)
 
 1. Clone the repo somewhere
-2. cargo build
-3. cargo run?
-4. ???
-5. go to `http://localhost:8282` (or whatever ip)
+2. cargo run?
+3. ???
+4. go to `http://localhost:8282` (or whatever ip)
 
 ### Production Deployment
 
@@ -53,13 +52,6 @@ I don't know how docker works so im writing this before I learn anything.
 2. do stuff so it works
 3. put it behind nginx (using examples from `/docs/`)
 
-## Developer Notes: Features implemented
-
-## Accounts / Monetisation
-
-Purely optional, only used for potential paid plans in the future.
-Future possibility of adding your own domain to the server, with custom theming working fine
-
 ## File limits and deletions
 
 2+ Deletion 'engines'
@@ -68,3 +60,24 @@ Future possibility of adding your own domain to the server, with custom theming
 2. Purely sized based deletion - Files are deleted based on their filesize
 3. Hybrid 'popularity' deletion - Files are deleted on a aggregate score based on size and popularity (large, popular files are kept alive longer, vs unpopular files most likely just used once)
 4. Lazy-Hybrid 'popularity' deletion - Files are deleted on size AND last view, depending on what comes last (small files stay the same, long files have potential to stay alive longer)
+
+## Database-less option
+
+There might be potential to have this running without using a database to save any information.
+For super lightweight versions, this would be neat.
+
+When files are uploaded, instead of adding to the DB, it writes the file to disk, and uses creation time as the 'uploaded date', and then each view, updating the access time, (or modified timed if atime is problematic)
+If the difference between creation and access times is too large (beyond ttd), delete the file.
+
+Other engine modes could be done similarly.
+
+### Advantages
+
+- Less resource usage (maybe, unless writing to a DB is less expensive than updating the last modified time)
+- Less complexity
+
+### Disadvantages
+
+- Less features
+- No tracking
+- Less Engine modes

docs/API.md

@@ -0,0 +1,46 @@
+# Ephemeral API Documentation
+
+All results are returned in JSON Formatting.
+
+## File Uploading - `/`
+
+POST - endpoint receives a file, returns the following.
+
+- URL
+- filename
+- **current** expiry
+- adminkey
+
+POST - endpoint receives a URL, returns the following.
+
+- URL
+- 'url' name (filename but for urls)
+- expiry (if enabled on server)
+- adminkey
+
+Returns 403 if the file is on the blocklist.
+Returns 401 if the server requires a key to upload files.
+
+GET - Returns the webpage, so be careful.
+
+## File information - `/edit/<key>`
+
+Returns information about the file with the corresponding key.
+
+- URL
+- filename
+- current expiry
+- popularity/fileviews
+
+If the key is invalid returns a 404, same with all children API Endpoints
+
+## File Deletion - `/edit/<key>/delete` (also `/delete/<key>` for backwards compatibility.)
+
+Deletes the file with the corresponding key. This is immediate and permanent.
+
+## File expiry Change - `/edit/<key>/ttd`
+
+If GET, reads the expiry from the DB and responds with it.
+If POST, tries it's best to overwrite the expiry. This will fail if the expiry is futher away than the current.
+
+This is in unix time.