Mostly, this is a change in ordering to make more sense, but we also
fix several names that were clearly confusing.
We restore the convention that each endpoint has the same title at the
top of the page as what we have in the sidebar menu, which appears to
have been violated in many recent updates to API documentation.
The term `parameter` is a better word than `argument` for data passed
to an API endpoint; this is why OpenAPI uses in their terminology.
Replace `argument` with `parameter` in the API docs to improve their
readability.
Fixes#15435.
Firstly, change endpoint descriptions in zulip.yaml so that they
match their counterpart in the api docs. Then edit the api docs
so that they use api description markdown extension for displaying
endpoint description.
Since the Zulip API runs on both developement and production
servers, it is misleading to mention "dev servers" when discussing
zuliprc files.
Also, note that it is better to manually edit all of our JS
examples than to implement macro-like functionality that we use
for our Python examples. For our current purposes, it would be
too much work to build a full-blown testing framework for our
JS code examples just so that we can fix a minor wording issue.
Fixes#10672.
In templates/zerver/api/delete-queue.md, we have a sample fixture
for when the queue_id passed to client.deregister_queue is not
valid or the event queue in question has already been deleted.
This commit tests that fixture.
Note that this error payload is specific to client.deregister_queue.
This commit modifies the Markdown extension in bugdown/api_code_examples.py
to support rendering code examples in multiple languages by specifying
the language like so:
{generate_code_example(python)|doc.md|example}
This makes us one step closer towards adding support for testable
JavaScript code examples.
We now have a separate page for common error payloads, for example,
the payload for when the client's API key is invalid. All error
payloads that are presented on this page will be tested similarly
to our other non-error sample fixtures.
It makes sense to make our Python and JS API examples more visible
than our curl examples, since Python is what most people will tend
to use.
Also, from a design perspective, an API documentation page that
starts off with a shiny Python example with syntax highlighting
looked much better than having a bland curl example be the first
thing readers see.
Kartik Srivastava
Tim Abbott
orientor
Vishnu Ks
Eeshan Garg
Yago González
Tim Abbott
Balaji2198