API inconsistencies

[fozcode]

• [x] If you delete a file/folder then delete it again you get a code 200, it should be a 404
• [x] The API returns HTML errors for "method not allowed" and for missing trailing slashes. Can we intercept these responses (coming from the middleware) and return JSON instead?
• [x] The file admin functions returns different fields to the file details function, make them more consistent (specifically the url, download, supported fields are missing from file admin operations)
• [x] Update the API docs

I don't think that any of these changes will break compatibility (you only get HTML errors for calls that are broken anyway).

[fozcode]

The file admin functions returns different fields than the file details function

The serialized image object is already consistent in:

• The admin/filesystem/images/ functions
• The admin/images/ functions
• The portfolios functions

There are inconsistencies though in the return value of image objects from:

• The list function (with attributes=1)
  • +url
  • +filename
  • +supported
  • -src
  • -status
  • -folder (object)
• The details and upload functions
  • +url
  • +download
  • -status
  • -folder (object)

The combined image object would be:

{
    "id": 524,
    "title": "my sample image",
    "description": "description of my sample image",
    "folder": {
      "id": 3,
      "name": "/test_images",
      "parent_id": 1,
      "path": "/test_images",
      "status": 1
    },
    "folder_id": 3,
    "width": 1600,
    "height": 1200,
    "src": "test_images/myimage.jpg",
    "filename": "myimage.jpg",
    "url": "https://images.example.com/image?src=test_images/myimage.jpg",
    "supported": true,
    "status": 1,
    "download": true
}

Where filename, url, supported and download are calculated fields.

For many scenarios the inclusion of the folder object is appropriate, but for some (list and upload) it is unnecessary because the folder is already known and will be the same for all images. As this task is about standardising the return value though, it seems best to me to keep it everywhere.