|
1 | 1 | # Examples |
2 | 2 |
|
3 | | -## Petstore |
| 3 | +| Example | Description | |
| 4 | +|---|---| |
| 5 | +| [Petstore](petstore.md) | Full walkthrough using the standard Petstore sample API | |
| 6 | +| [Authentication](authentication.md) | Configuring bearer token, API key, and basic authentication | |
| 7 | +| [Debugging](debugging.md) | Inspecting requests without sending them using mock mode | |
4 | 8 |
|
5 | | -This example uses the [Petstore](https://petstore3.swagger.io/api/v3/openapi.json) spec — a standard OpenAPI sample API. It has three operations under a `pets` tag and a public demo server, making it a good starting point. |
6 | | - |
7 | | -### 1. Generate the client |
8 | | - |
9 | | -Download the spec and run the generator: |
10 | | - |
11 | | -```bash |
12 | | -curl -o petstore.yaml https://petstore3.swagger.io/api/v3/openapi.json |
13 | | -openapidyalog petstore.yaml ./petstore-client |
14 | | -``` |
15 | | - |
16 | | -The generated output will be in `./petstore-client/APLSource/`. |
17 | | - |
18 | | -### 2. Load into Dyalog |
19 | | - |
20 | | -Start Dyalog APL and load the generated code with LINK: |
21 | | - |
22 | | -```apl |
23 | | - ]LINK.Create # ./petstore-client/APLSource |
24 | | -``` |
25 | | - |
26 | | -### 3. Create a client instance |
27 | | - |
28 | | -The Petstore spec declares a base URL; we pass it explicitly here: |
29 | | - |
30 | | -```apl |
31 | | - config ← (baseUrl: 'https://petstore3.swagger.io/api/v3') |
32 | | - client ← ⎕NEW Client config |
33 | | -``` |
34 | | - |
35 | | -### 4. List pets |
36 | | - |
37 | | -```apl |
38 | | - response ← client.pets.ListPets () |
39 | | - response.HttpStatus |
40 | | -200 |
41 | | - response.Data |
42 | | -#.[JSON object] |
43 | | -``` |
44 | | - |
45 | | -The response body is parsed automatically from JSON into a namespace. Individual pets are accessible as elements of the returned array. |
46 | | - |
47 | | -### 5. Fetch a pet by ID |
48 | | - |
49 | | -```apl |
50 | | - response ← client.pets.ShowPetById (petId: 1) |
51 | | - response.HttpStatus |
52 | | -200 |
53 | | - response.Data.name |
54 | | -doggie |
55 | | -``` |
56 | | - |
57 | | -### 6. Check for errors |
58 | | - |
59 | | -```apl |
60 | | - response ← client.pets.ShowPetById (petId: 9999) |
61 | | - response.HttpStatus |
62 | | -404 |
63 | | - response.IsOK |
64 | | -0 |
65 | | -``` |
66 | | - |
67 | | -See [Error Handling](../generated-client/error-handling.md) for how to handle this in production code. |
68 | | - |
69 | | ---- |
70 | | - |
71 | | -## Bearer token authentication |
72 | | - |
73 | | -This example shows how to configure a client for an API that requires a bearer token. |
74 | | - |
75 | | -```apl |
76 | | - config ← ( |
77 | | - baseUrl: 'https://api.example.com' |
78 | | - security: (bearerToken: 'env:[API_TOKEN]') |
79 | | - ) |
80 | | - client ← ⎕NEW Client config |
81 | | -``` |
82 | | - |
83 | | -Setting the `bearerToken` field to `env:[API_TOKEN]` causes the client to read the value of the `API_TOKEN` environment variable at request time, so the token is never hardcoded. With the token set in the environment: |
84 | | - |
85 | | -```bash |
86 | | -export API_TOKEN=my-secret-token |
87 | | -``` |
88 | | - |
89 | | -Requests will include the header `Authorization: Bearer my-secret-token` automatically. |
| 9 | +More examples are planned. |
0 commit comments