Commit 491b8883 authored by Ben Boeckel's avatar Ben Boeckel
Browse files

doc: update README with new API docs

parent b830edf2
Pipeline #175464 passed with stages
in 5 minutes and 22 seconds
......@@ -7,21 +7,26 @@ The API is based off of the GitLab 13.00 API v4 and will likely aggressively tra
new API additions, so the newest release may not support talking to older
releases where fields have been added.
All API types should be implemented in the [types](src/types.rs) module. These
types should generally be implemented based on the `lib/api/entities.rb`
module in the Gitlab repository. However, in the interest of usability,
entities may be combined using `Option` to handle the differences. Generally,
this should be done where the difference is "small". As a concrete example,
the `Project` entity has dozens of fields and `ProjectWithAccess` has one
additional field (`permissions`) which is added using `Option` rather than
creating a new `ProjectWithAccess` structure which only differs in this field.
The endpoints that are supported all live under the [`api`](src/api.rs) module.
Each endpoint may be constructed using a "builder" pattern to provide supported
fields. To use an endpoint, you may query it using the
[`Query`](src/api/query.rs) trait. There are additional helpers to handle
different cases:
In short, map the API as close as possible, but also know when to bend the
rules.
- [`api::ignore`](src/api/ignore.rs): Ignore the GitLab response (useful for
`POST` or `PUT` endpoints).
- [`api::paged`](src/api/paged.rs): Fetch results that are paginated.
- [`api::raw`](src/api/raw.rs): Return the raw data from GitLab instead of
deserializing into a structure.
- [`api::sudo`](src/api/sudo.rs): Modify an endpoint using GitLab's `sudo`
parameter for masquerading as another user (requires an administrator
token).
If you run into places where Gitlab dumps a JSON value rather than an actual
entity, please consider updating upstream to use a real entity so that changes
to the structure are easier to track.
All endpoints return data types of the caller's choosing that implement
`serde`'s `Deserialize` trait. Callers should define their own structures for
obtaining data from the API. This allows the structure to be more easily
changeable for different GitLab versions (rather than this crate being pinned
to a given version).
# Versioning
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment