You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Foundry Local allows you to develop and integrate your own catalog service. This document provides guidance on:
21
+
Foundry Local lets you build and integrate your own catalog service. This article covers:
21
22
22
-
-The model format required for the catalog API.
23
-
-The request and response format required for your catalog API to integrate with Foundry Local.
23
+
-Model format required for the catalog API
24
+
-Request and response format required for your catalog API to integrate with Foundry Local
24
25
25
26
## Model format
26
27
27
-
The model files hosted in your model catalog are required to be in the [Open Neural Network Exchange (ONNX)](https://onnx.ai/) format to work with Foundry Local. For more information on how to compile Hugging Face and PyTorch models to ONNX, see the [Compile Hugging Face models to run on Foundry Local](../how-to/how-to-compile-hugging-face-models.md) article.
28
+
Model files in your model catalog must be in the [Open Neural Network Exchange (ONNX)](https://onnx.ai/) format to work with Foundry Local. To learn how to compile Hugging Face and PyTorch models to ONNX, see [Compile Hugging Face models to run on Foundry Local](../how-to/how-to-compile-hugging-face-models.md).
28
29
29
30
## API format
30
31
31
32
### Request
32
33
33
-
Your catalog service needs to support a POST endpoint that accepts a JSON request body. The request format for the catalog API is as follows:
34
+
Implement a POST endpoint that accepts a JSON request body in your catalog service. The request format for the catalog API is as follows:
34
35
35
36
-**Method**: `POST`
36
37
-**Content-Type**: `application/json`
37
38
38
-
The request body *must* be a JSON object that *accepts* the following fields:
39
+
The request body must be a JSON object with the following fields:
39
40
40
-
-`resourceIds`: An array of resource IDs that specify the resources to be queried.
41
-
-`resourceId`: The ID of the resource.
42
-
-`entityContainerType`: The type of entity container (for example, `Registry`, `Workspace`, etc.).
41
+
-`resourceIds`: An array of resource IDs that specify the resources to be queried
42
+
-`resourceId`: The ID of the resource
43
+
-`entityContainerType`: The type of entity container (for example, `Registry`, `Workspace`, etc.)
43
44
-`indexEntitiesRequest`: An object that contains the search parameters.
44
-
-`filters`: An array of filter objects that specify the criteria for filtering the search results.
45
-
-`field`: The field to filter on (for example, `type`, `kind`, etc.).
45
+
-`filters`: An array of filter objects that specify the criteria for filtering the search results
46
+
-`field`: The field to filter on (for example, `type`, `kind`, etc.)
46
47
-`operator`: The operator to use for the filter. For example, `eq` (equals), `ne` (not equals), `gt` (greater than), `lt` (less than), etc.
47
-
-`values`: An array of values to match against the field.
48
-
-`orderBy`: An array of fields to order the results by.
49
-
-`searchText`: A string to search for in the results.
50
-
-`pageSize`: The maximum number of results to return (for pagination).
51
-
-`skip`: The number of results to skip (for pagination).
52
-
-`continuationToken`: A token for pagination to continue from a previous request.
48
+
-`values`: An array of values to match against the field
49
+
-`orderBy`: An array of fields to order the results by
50
+
-`searchText`: A string to search for in the results
51
+
-`pageSize`: The maximum number of results to return (for pagination)
52
+
-`skip`: The number of results to skip (for pagination)
53
+
-`continuationToken`: A token for pagination to continue from a previous request
53
54
54
-
#### Filterable Fields (optional)
55
+
#### Filterable fields (optional)
55
56
56
-
You *must* implement your catalog API that *accepts* the [Request](#request) format, but it's *optional* as to whether you implement server-side filtering in your catalog service. Not implementing server-side filtering is a fast way to implement your catalog service, but it might not be efficient way to search for models.
57
+
Implement the catalog API so it accepts the [Request](#request) format. Server-side filtering is optional. Skipping server-side filtering is faster to implement but is less efficient for searching models.
57
58
58
-
If you choose to implement server-side filtering, you can use the following fields to filter the results:
59
+
If you implement server-side filtering, use the following fields:
59
60
60
61
-`type`: The type of the model (for example, `models`, `datasets`, etc.).
61
62
-`kind`: The kind of the model (for example, `Versioned`, `Unversioned`, etc.).
@@ -66,7 +67,7 @@ If you choose to implement server-side filtering, you can use the following fiel
66
67
#### Example request
67
68
68
69
```bash
69
-
curl POST <your-catalog-api-endpoint> \
70
+
curl -X POST <your-catalog-api-endpoint> \
70
71
-H "Content-Type: application/json" \
71
72
-d '{
72
73
"resourceIds": [
@@ -144,8 +145,8 @@ The response from the catalog API is a JSON object that contains the search resu
144
145
},
145
146
"continuationToken": {
146
147
"type": "string",
147
-
"description": "A token to continue fetching results."
148
-
},
148
+
"description": "A token to continue fetching results."
149
+
}
149
150
}
150
151
}
151
152
},
@@ -174,7 +175,7 @@ The response from the catalog API is a JSON object that contains the search resu
0 commit comments