text ", and accept parameters in the URL hierarchy, from POSTed JSON, in URI query string params, and for API keys, in an Authorization header. Most parameters are optional, with the only required parameters specified as part of the URL hierarchy."
text "All endpoints return HTTP status 200 when successful, as well as a JSON object ("
code '{ "success": true }'
text ") with a success boolean and extra data depending on the endpoint. When errors are encountered, a non-200 HTTP status code is sent, along with a JSON object ("
pre -> code title: "(This example is a real task that I added while developing this API. :P)", "{\"success\":true,\"task\":{\"created_at\":\"2018-04-24 14:15:04\",\"id\":12,\"content\":\"Make index return a logged_out view instead of redirecting to login\",\"done\":true,\"user_id\":1,\"updated_at\":\"2018-04-25 04:28:36\"}}"
p "Authorization is done by sending an API key along with other parameters. It can be sent as an Authorization header, in a URI query string (not recommended), or as part of a POSTed JSON object."
text " represents an optional URI-encoded string (for "
code "/new/:content"
text " only), and "
code ":selector"
text " represents an integer for selecting via ID, or a URI-encoded string for selecting via content (generally not recommended). All endpoints except "
p "The API can be used to request new API keys and delete API keys, but cannot be used to look up API keys, or perform any other actions with API keys."
p "At this time there is no rate limiting. This will be developed when needed, and the API documentation updated to reflect that, with at least 2 months' warning."
text " not returning tasks (just success boolean or errors)."
li ->
text "Added "
code "/edit"
text " endpoint for modifying tasks."
li ->
text "Removed "
code "id"
text " from API keys, as they weren't working anyhow, and aren't neccesary."
li "Added the ability to make requests using a URI and an authorization method only, which should make it easier to develop apps for. (More flexibility in how the API can be used.)"
li "Extensively rewrote the API documentation. *wipes sweat from brow*"
p "All API versions will be supported indefinitely, unless a new feature requires a backwards-incompatible change to the database. In that case, an API will be marked deprecated and will remain available for at least 6 months."
p "All new features that do not require modifications to existing API calls will be added to v1 as they are introduced. The next version of the API will only exist if backwards-incompatible changes to the API itself are introduced."
text " endpoint. The web interface will also be updated to utilize this."
li "Lists (including the ability to have lists of lists). The API and web interface will receive several updates for this."
li ->
code "/duplicate"
text " endpoint for duplicating a task or list (with optional inclusion of any sub-tasks/sub-lists). The web interface will be updated to utilize this."
text "Data export. (Note: Initially will be a large JSON dump, but you can contact me if you have special needs for data export and I will develop these upon request.)"
ul -> li "Will be API-based, with options for which tasks to include or exclude, defaulting to exporting everything."
li "Reordering tasks/lists. (This one requires some research on my part of how to implement this efficiently.)"
li "Tagging system (for tasks/lists)."
li "Due dates/times."
li "Webhooks."
li "OAuth2 support."
li "Import from other todo/task management software."
p "Finally, this is a list of a few site-related things I need to get set up:"
ul ->
li "A homepage for non-users showing features / enticing sign-up. Of course. :P"
li "A dynamically updated page showing project status, both in terms of budget (income/expenses) and features/bugs. (This will also allow users to vote for features/bugs to be prioritized.)"
li "A page for accepting payments. At this stage, this is optional and I will be relying purely on people wanting to see this system succeed. In the future, more advanced API features may be behind a subscription model (intended to be $1.50/year)."
p "All routes are technically available by any HTTP verb. However, depending on the HTTP spec for the verb you use, this may cause required data to not be parsed correctly."
p "I would recommend sticking to POST requests, but GET works for sure, and /new might work with anything if the content is specified in the URL." -- TODO clean up format here
p "Do not write your code expecting ONLY the data specified here, as more features are added, more data will be in the task objects returned."
