[RFC] API - Clean up SQL tables, initial implementation, and more.

[RePod]

Most of this information is based on _test.php_ at the time of writing.

---

As we shift into making an API, the largest obstacle is translating the rows properly from the SQL server to something expected to be someone human-readable (JSON).

The database and code itself is plagued with, at best, hard to guess versions of words that have no reason to be abbreviated.

For example: w, h, tn_w, tn_h, fname, and fsize can all reasonably be guessed but add an extra step to the eventual API, slowing it down.

• resto is vague to those not familiar with the back-end at all.
• sub and com can be expanded.
  • Currently done passively in my API implementation.
• The md5 column has no length limit, despite a valid hash being no more than 32 characters.
• tim appears to be the stored file's name, again misleading.
  • Relocated to post.file.local_name in my API implementation.

now could be anything. however it's a text type. A UTC time stamp (in seconds)? An already converted date? Yep.

Across the board these changes might add a couple kilobytes of text, but with the benefit of improving readability when handling table data.

[RePod]

I've address a few of my complaints with temporary workarounds in my initial API implementation.

• Relocated tim: 83fae3c69d68671efc0faa6fde1828a5b91c9bde

[RePod]

In action: (using a viewer)

• OP JSON
• Reply JSON

Ideally the output .json files should be stored in RES_DIR for ease of access or use .htaccess (aka wouldn't work on non-Apache) to reroute seemingly valid requests to a different folder. There's currently no API result for catalog/index pages, just individual post numbers, therefore:

• Update the OP JSON when first posted, and each time it gets a reply.
• Update reply JSON when first posted and if it's later modified (delete, admin, etc).

[RePod]

Partially addressed by #220 and what it does to the tables, except the API now needs to be updated to reflect it.

[RePod]

Probably good to close, especially since #220 was merged which fixed almost everything related to where the columns were (but not what they were named). We clearly don't care about improving self-documenting and human-readable column names like sub and com so no worries.

The only questionable column right now is the media column in the post table. It currently serves no purpose but if we ever need it it's already there.

[RePod]

As mentioned above, except progress has resumed and the media column is functional. In general, the API will require minor rewrites to function at all but even more to reach "@Apogate approved clone" status.

Current suggestions from Anonymous sources:

• Single JSON per-thread
• Purge empty keys
• Better type casting
  • Write out true/false

[RePod]

253 when through, unfortunately. And lacks multi-file support.