codegen rust crate for v0.3.3

1 files changed, 4 insertions, 4 deletions

diff --git a/rust/fatcat-openapi/README.md b/rust/fatcat-openapi/README.md
index 1e02e033..27137793 100644
--- a/rust/fatcat-openapi/README.md
+++ b/rust/fatcat-openapi/README.md
@@ -1,6 +1,6 @@
 # Rust API for fatcat
 
-Fatcat is a scalable, versioned, API-oriented catalog of bibliographic entities and file metadata.  <!-- STARTLONGDESCRIPTION --> These API reference documents, along with client software libraries, are generated automatically from an OpenAPI 2.0 (\"Swagger\") definition file.  ## Introduction   A higher-level introduction to the API, as well as a description of the fatcat data model, are available in [\"The Fatcat Guide\"](https://guide.fatcat.wiki/). The guide also includes a [Cookbook](https://guide.fatcat.wiki/cookbook.html) section demonstrating end-to-end tasks like creating entities as part of editgroups, or safely merging duplicate entities.  ### Expectations and Best Practices  A test/staging QA API instance of fatcat is available at <https://api.qa.fatcat.wiki/v0>. The database backing this instance is separate from the production interface, and is periodically rebuilt from snapshots of the full production database, meaning that edits on the QA server will *NOT* persist, and that semantics like the changelog index monotonically increasing *MAY* be broken. Developers are expexcted to test their scripts and tools against the QA instance before running against production.  Fatcat is made available as a gratis (no cost) and libre (freedom preserving) service to the public, with limited funding and resources. We welcome new and unforseen uses and contributions, but may need to impose restrictions (like rate-limits) to keep the service functional for other users, and in extreme cases reserve the option to block accounts and IP ranges if necessary to keep the service operational.  The Internet Archive owns and operates it's own server equipment and data centers, and operations are optimized for low-cost, not high-availability. Users and partners should expect some downtime on the fatcat API, on the order of hours a month.  Periodic metadata exports are available for batch processing, and database snapshots can be used to create locally-hosted mirrors of the service for more intensive and reliable querying.  ### Other Nitty Gritties  Cross-origin requests are allowed for the API service, to enable third parties to bulid in-browser applications.  A metadata search service is available at <https://search.fatcat.wiki> (and <https://search.qa.fatcat.wiki>). The API is currently the raw elasticsearch API, with only GET (read) requests allowed. This public service is experimental and may be removed or limited in the future.  ## Authentication  The API allows basic read-only \"GET\" HTTP requests with no authentication. Proposing changes to the metadata, or other mutating requests (\"PUT\", \"POST\", \"DELETE\") all require authentication, and some operations require additional account permissions.  End-user account creation and login happens through the web interface. From a logged-in editor profile page, you can generate a API token. Tokens are \"macaroons\", similar to JWT tokens, and are used for all API authentication. The web interface includes macaroons in browser cookies and passes them through to the API to authenticate editor actions.  <!-- ReDoc-Inject: <security-definitions> --> <!-- ENDLONGDESCRIPTION --> 
+Fatcat is a scalable, versioned, API-oriented catalog of bibliographic entities and file metadata.  <!-- STARTLONGDESCRIPTION --> These API reference documents, along with client software libraries, are generated automatically from an OpenAPI 2.0 (\"Swagger\") definition file.  ## Introduction   A higher-level introduction to the API, as well as a description of the fatcat data model, are available in [\"The Fatcat Guide\"](https://guide.fatcat.wiki/). The guide also includes a [Cookbook](https://guide.fatcat.wiki/cookbook.html) section demonstrating end-to-end tasks like creating entities as part of editgroups, or safely merging duplicate entities.  ### Expectations and Best Practices  A test/staging QA API instance of fatcat is available at <https://api.qa.fatcat.wiki/v0>. The database backing this instance is separate from the production interface, and is periodically rebuilt from snapshots of the full production database, meaning that edits on the QA server will *NOT* persist, and that semantics like the changelog index monotonically increasing *MAY* be broken. Developers are expexcted to test their scripts and tools against the QA instance before running against production.  Fatcat is made available as a gratis (no cost) and libre (freedom preserving) service to the public, with limited funding and resources. We welcome new and unforseen uses and contributions, but may need to impose restrictions (like rate-limits) to keep the service functional for other users, and in extreme cases reserve the option to block accounts and IP ranges if necessary to keep the service operational.  The Internet Archive owns and operates it's own server equipment and data centers, and operations are optimized for low-cost, not high-availability. Users and partners should expect some downtime on the fatcat API, on the order of hours a month.  Periodic metadata exports are available for batch processing, and database snapshots can be used to create locally-hosted mirrors of the service for more intensive and reliable querying.  ### Other Nitty Gritties  Cross-origin requests are allowed for the API service, to enable third parties to build in-browser applications.  A metadata search service is available at <https://search.fatcat.wiki> (and <https://search.qa.fatcat.wiki>). The API is currently the raw elasticsearch API, with only GET (read) requests allowed. This public service is experimental and may be removed or limited in the future.  ## Authentication  The API allows basic read-only \"GET\" HTTP requests with no authentication. Proposing changes to the metadata, or other mutating requests (\"PUT\", \"POST\", \"DELETE\") all require authentication, and some operations require additional account permissions.  End-user account creation and login happens through the web interface. From a logged-in editor profile page, you can generate a API token. Tokens are \"macaroons\", similar to JWT tokens, and are used for all API authentication. The web interface includes macaroons in browser cookies and passes them through to the API to authenticate editor actions.  <!-- ReDoc-Inject: <security-definitions> --> <!-- ENDLONGDESCRIPTION --> 
 
 ## Overview
 This client/server was generated by the [swagger-codegen]
@@ -12,8 +12,8 @@ To see how to make this your own, look here:
 
 [README](https://github.com/swagger-api/swagger-codegen/blob/master/README.md)
 
-- API version: 0.3.1
-- Build date: 2019-09-19T00:21:33.977Z
+- API version: 0.3.3
+- Build date: 2020-11-17T23:34:45.205Z
 For more information, please visit [https://fatcat.wiki](https://fatcat.wiki)
 
 This autogenerated project defines an API crate `fatcat` which contains:
@@ -171,7 +171,7 @@ The server example is designed to form the basis for implementing your own serve
 
 * Set up a new Rust project, e.g., with `cargo init --bin`.
 * Insert `fatcat` into the `members` array under [workspace] in the root `Cargo.toml`, e.g., `members = [ "fatcat" ]`.
-* Add `fatcat = {version = "0.3.1", path = "fatcat"}` under `[dependencies]` in the root `Cargo.toml`.
+* Add `fatcat = {version = "0.3.3", path = "fatcat"}` under `[dependencies]` in the root `Cargo.toml`.
 * Copy the `[dependencies]` and `[dev-dependencies]` from `fatcat/Cargo.toml` into the root `Cargo.toml`'s `[dependencies]` section.
   * Copy all of the `[dev-dependencies]`, but only the `[dependencies]` that are required by the example server. These should be clearly indicated by comments.
   * Remove `"optional = true"` from each of these lines if present.