Skip to main content

okapi

https://circleci.com/gh/Team-Zeus/okapi/tree/master.svg?style=svg&circle-token=71c675badd691f1e9e51bee3633b8fcf105497d6

To have API documentation OK.

Okapi is a simple tool to create documentation for your API and cover it with tests. It is based on reStructuredText format and very easy to learn.



Okapi

Requirements

  • Python 3.4

For developing install requirements from requirements.txt.

pip install -r requirements.txt

Installation

sudo pip3 install tz-okapi

Install from sources:

python setup.py install

Install from package:

pip install wheel
pip install tz_okapi-*.whl

On Windows you might add Python to paths:

setx path "%path%;C:\Python34;C:\Python34\Scripts;"

Usage

okapi

Usage:
    okapi [<in> -cdo <out> --url=<url> --config=<config> --headers=<headers> -v <verbosity> --prototype]

Options:
    -c                      Enable persistent cache for responses.
    -d                      Allow debug mode.
    -o <out>                Output directory
    -v <verbosity>          Verbosity level [default: 2]
                                0 - no output
                                1 - summary
                                2 - failed tests
                                3 - all

    --url=<url>             URL against the requests are made
    --headers=<headers>     Custom headers sent to API, not visible in doc.
                            (Comma separated).
    --config=<config>       Config file. [default: okapi.cfg]
    --prototype             Run in prototype mode (no requests are made).

Example:
    okapi notebook.rst -o index.html --url=http://www.notebook.com/

Example configuration file

[base]
file = notebook-api.rst
output = docs/api
url = http://www.mynotebook/
cache = 1
templates = docs/api/templates
verbosity = 2

Example

Notebook API documentation
==========================

Notebook is a project to create and read notes.

In every request, it should be sent this headers:

.. code:: headers

  Accept-Type: application/json
  Accept-Language: en,fr


Create new note
---------------

To create new note use this POST method. Note can be created
only with authenticated user.

.. code:: request

  POST /api/note/create/
  Authentication: johnsmith:topsecretpass

  {
    "title": "My Note Title",
    "text": "Very long text..."
  }

  > status_code == 201
  > 'id' in json()

If user is not successfully authenticated, status code ``401``
is returned:

.. code:: request

  POST /api/note/create/

  > status_code == 401


Get note detail
---------------

To get note detail, you have to provide its ``id``.

For example:

.. code:: request

  GET /api/note/{id:1}/

  > status_code == 200
  > 'title' in json()
  > 'text' in json()


Get notes list
--------------

To get all notes use this request:

.. code:: request

  GET /api/notes/

  > status_code == 200

It is possible to filter by creation date:

.. code:: request

  GET /api/notes/?date=2015-01-01

  > status_code == 200

Not enough? Continue in reading…

Motivation

We were long time looking for a tool to create documentation for APIs of our projects. We tried Apiary, we tried Swagger and more and more tools, but none has satisfied us.

We needed tool, which would be:

  • DRY. We are lazy to repeat our selves. Repeating is a way do many mistakes.

  • KISS. Every member of team should be able to edit it without knowing some special syntax or rules. So super stupid simple.

  • Changeable. It means, that man wouldn’t edit documentation for hours after every small change in API.

  • Readable in raw format.

  • Usable for non-REST APIs (but for REST API, too, of course).

  • Testable. Documentation not covered with tests is hard to maintance.

Specification

headers

Block used at the beginning of document to set common headers sent with request and disabled headers hidden from response. It should be used only once.

.. code:: headers

  [HEADER_NAME: HEADER_VALUE]
  ...

request

Block to describe API request. It has four parts:

  1. method and url (required)

  2. headers (optional)

  3. payload (optional)

  4. tests (recommended)

.. code:: request

    (GET|POST|PUT|PATCH|DELETE|OPTIONS|HEAD|TRACE|CONNECT) (URL) [HTTP_VERSION]
    [HEADER_NAME: HEADER_VALUE]
    ...

    [{ ... json payload ... }]

    [
    > tests
    > ..
    ]

url

URL cannot contain any space. Use encoded strings (%20 or +).

URLs can be with described params:

{NAME:VALUE}

eg.:

/api/note/{typeId:1}/{noteId:3}/

Change log

Release 0.2.10 (2015/09/24)

  • Disable redirects in API requests.

Release 0.2.9 (2015/09/22)

  • Fix UnicodeEncodeError during saving output.

Release 0.2.8 (2015/08/05)

  • #32 - Add MIT license

  • #33 - Fix bad interpreter error.

Release 0.2.7 (2015/08/04)

  • #12 - Fix path with using of include directive.

Release 0.2.6 (2015/08/04)

  • #30 - Added --prototype option to run in prototype mode. Prototype mode doesn’t execute any request, responses are faked.

  • #31 - Added automatically generated sidebar TOC to default template.

Release 0.2.5 (2015/07/27)

  • #27 - Added click on scroll functionality. Request and response are not scrollable by default, user has to click on them.

  • #26 - Fixed default template to show response status code even if response is empty.

Metadata

Release files for tz-okapi 0.2.10

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for tz-okapi 0.2.10
File Interpreter ABI Platform
tz_okapi-0.2.10-py2.py3-none-any.whl Python 3, Python 2 none any Details

Release files / tz_okapi-0.2.10-py2.py3-none-any.whl

Download URL tz_okapi-0.2.10-py2.py3-none-any.whl
Size 32.5 kB
Tags Python 2 Python 3
SHA-256 checksum
How to use checksums
04c9478c7e00e507e23a9e207a824f167ca7cb08f2eac8d639d7c247476a9dda
BLAKE2b-256 checksum
How to use checksums
ae4d4fbf1293555ba99aa261066fc5517c4ac60d14c0815db821c892ae566914
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No

Security for tz-okapi 0.2.10

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page