# zyte-api-rs
Allows access to the Zyte API proxy service.
This is an unofficial, unstable, unfinished crate. However normal usage with `HTTP GET` should work fine.
## Prerequisites
- You must have an account & API token from Zyte for their proxy API service:
- Currently this crate only supports `async`/`await` usage so you must use an async executor e.g. .
## Installation
```bash
cargo add zyte-api-rs
```
## Example
```rust
use zyte_api_rs::ZyteApi;
#[tokio::main]
async fn get_google() {
let zyte_api = ZyteApi::new("");
// simple GET
let response = zyte_api.get("https://www.google.com/").await.unwrap();
// status_code is from http::Method
if response.status_code.is_success() {
println!("{}", response.http_response_body);
}
let response = zyte_api
.post("https://httpbin.org/post")
.unwrap()
.text(r#"{"custname": "foobar"}"#)
.send()
.await
.unwrap();
if response.status_code.is_success() {
println!("{}", response.http_response_body);
}
}
```
## Features
### Requests
- [ ] `HTTP`
- [x] `GET`
- [ ] `POST`
- [ ] `httpResponseBody`
- [ ] `httpResponseText`
- [ ] `Browser`
- [ ] `Headers`
### Responses
- [ ] Normal Responses
- [ ] Error Responses
## Design Goals
- Have `zyte-api-rs`'s `Response` object mirror (as much as possible) the structure of the `Response` schema from the official api:
- Have an easy-to-use "builder" interface similar to
- The json structure of requests to the zyte api are a bit complicated, with mutually-exclusive keys for different features -- this project aims to "make invalid states unrepresentable"
- Learn Idiomatic Rust -- please file issues for code that is poorly written: .
## Notes
- The status code is actually an instance of [`http::StatusCode`](https://docs.rs/http/latest/http/status/struct.StatusCode.html) which allows more useful semantics such as `status_code.is_success()`.