POST to /db/canned-query that returns JSON should be supported (for API clients)

[simonw]

Now that CSRF is solved for API requests (#835) it would be good to support API requests to the .json extension.

[simonw]

The response from this will never be a 302 - it will always be a 200 if the response worked or a 400 for bad parameters or a 500 for errors. The body returned will always be in JSON format.

[simonw]

I've been testing the WIP using this in the console:

fetch('/data/add_name.json', {
  method: 'POST',
  body: 'name=XXXfetch',
  credentials: 'omit',
  headers: {'Content-Type': 'application/x-www-form-urlencoded'}
})
.then(response => console.log(response))

Against a canned query configured like this:

databases:
  data:
    queries:
      add_name:
        sql: insert into names (name) values (:name)
        write: true

I haven't got it to work yet. Latest error is this one:

INFO:     Uvicorn running on http://127.0.0.1:8001 (Press CTRL+C to quit)
Traceback (most recent call last):
  File "/Users/simon/Dropbox/Development/datasette/datasette/app.py", line 975, in route_path
    await response.asgi_send(send)
AttributeError: 'tuple' object has no attribute 'asgi_send'
INFO:     127.0.0.1:49938 - "POST /data/add_name.json HTTP/1.1" 500 Internal Server Error

It looks like I'm going to have to rethink how the BaseView code around tables, formats and hashes is structured in order to fix this. That's a big refactoring! I'm moving this to a new milestone for Datasette 0.46.

[simonw]

What should happen when something does a POST to an extension that was registered by a plugin, e.g. POST /db/table.atom ?

[simonw]

Maybe POST to .json doesn't actually make sense. I could instead support POST /db/queryname with an optional mechanism for requesting that the response to that POST be in a JSON format.

Could be a Accept: application/json header with an option of including "_accept": "json" as a POST parameter instead.

[simonw]

Is it safe to skip CSRF checks if the incoming request has Accept: application/json on it?

I'm not sure that matters since asgi-csrf already won't reject requests that either have no cookies or are using a Authorization: Bearer ... header.