issue_comments: 1352335503
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | issue | performed_via_github_app |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/simonw/datasette/issues/1949#issuecomment-1352335503 | https://api.github.com/repos/simonw/datasette/issues/1949 | 1352335503 | IC_kwDOBm6k_c5QmwCP | 9599 | 2022-12-14T23:03:28Z | 2022-12-14T23:03:28Z | OWNER | This raises a more complicated issue At some point I'm likely to want to add an HTML interface for creating tables and inserting and updating rows. The obvious URLs for that are the same as for the JSON API: `/db/table/-/insert` and suchlike. Those endpoints are currently POST only - and can return JSON all the time. If they start accepting form POSTs too they'll need to be able to accept form-encoded data and return HTML instead. That's OK - they can detect incoming JSON thanks to the `content-type` header an the fact that the request body starts with `{` - but the `should_return_json` fix described above could intefere with how errors are returned if I'm not careful. I think it can still work though: I'll only set `should_return_json = True` if the endpoint gets a POST with a body starting `{`, or a content-type JSON header. | {"total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0} | 1493471221 |