Mercurial > p > roundup > code
view test/README.txt @ 5632:a29a8dae2095
Initial implementation of function to return data for / and /data
endpoints under /rest/.
/rest/ returns:
1) default_version of the interface and supported_version array
2) list of links with rel and uri properties that indicate
what assets are available under /rest. E.g. /rest/data
/data returns:
a list of possible assets (e.g. issue, user, keyword, status)
and links for accessing those assets.
E.G.
{
"data": {
"keyword": {
"link": "https://example.net/demo/rest/data/keyword"
},
"user": {
"link": "https://example.net/demo/rest/data/user"
}, ...
}
}
Both of these are currently hand coded. Others will be doing more
development on the rest interface. These two examples are meant to
spark discussion on what the payloads returned by the rest interface
should look like and give some ideas around HATEOAS.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Fri, 01 Mar 2019 23:24:40 -0500 |
| parents | a86b0c02940d |
| children | 132d450bdc00 |
line wrap: on
line source
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)
