Added support for accepting application/json payload in addition to the existing application/x-www-form-urlencoded. The key for this is that the third element of the FieldStorage is a string as opposed to a list. So the code checks for the string and that the Content-Type is exactly application/json. I do a string match for the Content-Type. This code also adds testing for the dispatch method of RestfulInstance. It tests dispatch using GET, PUT, POST, PATCH methods with json and form data payloads. Existing tests bypass the dispatch method. It moves check for pretty printing till after the input payload is checked to see if it's json. So you can set pretty in the json payload if wanted. Adds a new class: SimulateFieldStorageFromJson. This class emulates the calling interface of FieldStorage. The json payload is parsed into this class. Then the new object is passed off to the code that expects a FieldStorage class. Note that this may or may not work for file uploads, but for issue creation, setting properties, patching objects, it seems to work. Also refactored/replaced the etag header checks to use a more generic method that will work for any header (e.g. Content-Type). Future enhancements are to parse the full form of the Content-Type mime type so something like: application/vnd.roundup.v1+json will also work. Also the SimulateFieldStorageFromJson could be used to represent XML format input, if so need to rename the class dropping FromJson. But because of the issues with native xml parsers in python parsing untrusted data, we may not want to go that route. curl examples for my tracker is: curl -s -u user:pass -X POST --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data '{"title": "foo bar", "fyi": "text", "private": "true", "priority": "high" }' \ -w "http status: %{http_code}\n" \ "https://example.net/demo/rest/data/issue" { "data": { "link": "https://example.net/demo/rest/data/issue/2229", "id": "2229" } } http status: 201

A number of tests uses the infrastructure of
	db_test_base.py

grep "from db_test_base" -l *.py
benchmark.py
session_common.py
test_anydbm.py
test_indexer.py
test_memorydb.py
test_mysql.py
test_postgresql.py
test_security.py
test_sqlite.py
test_userauditor.py

grep "import db_test_base" -l *.py
test_cgi.py
test_jinja2.py
test_mailgw.py
test_xmlrpc.py

grep "import memory\|from memory" -l *.py 
test_mailgw.py
test_memorydb.py


The remaining lines are an 2001 description from Richard,
which probably is outdated:

Structure of the tests:

   1   Test date classes
   1.1 Date
   1.2 Interval
   2   Set up schema
   3   Open with specific backend
   3.1 anydbm
   4   Create database base set (stati, priority, etc)
   5   Perform some actions
   6   Perform mail import
   6.1 text/plain
   6.2 multipart/mixed (with one text/plain)
   6.3 text/html
   6.4 multipart/alternative (with one text/plain)
   6.5 multipart/alternative (with no text/plain)