|
2497 | 2497 | "post": { |
2498 | 2498 | "summary": "\nSearch an index for entities of interest\n, with filters provided in the request body.\n", |
2499 | 2499 | "deprecated": true, |
2500 | | - "description": "\nAny of the query parameters documented below can alternatively be passed\nas a property of a JSON object in the body of the request. This can be\nuseful in case the value of the `filters` query parameter causes the URL\nto exceed the maximum length of 8192 characters, resulting in a 413\nRequest Entity Too Large response.\n\nThe request `GET /index/files?filters={\u2026}`, for example, is equivalent to `POST /index/files`\nwith the body `{\"filters\": \"{\u2026}\"}` in which any double quotes or\nbackslash characters inside `\u2026` are escaped with another backslash. That\nescaping is the requisite procedure for embedding one JSON structure\ninside another.\n\n\nNote that the Swagger UI can't currently be used to pass a body.\n\nPlease also note that this endpoint should be considered beta and\nmay change or disappear in the future. That is the reason for the\ndeprecation.\n", |
| 2500 | + "description": "\nAny of the query parameters documented below can alternatively be passed\nas a property of a JSON object in the body of the request. This is\nreferred to as *parameter hoisting* and can be useful in case the value\nof the `filters` query parameter causes the URL to exceed the maximum\nlength of 8192 characters, resulting in a 413 Request Entity Too Large\nresponse.\n\nThe request `GET /index/files?filters={\u2026}`, for example, is equivalent to `POST /index/files`\nwith a `Content-Type` header of `application/json` and the body\n`{\"filters\": \"{\u2026}\"}` in which any double quotes or backslash characters\ninside `\u2026` are escaped with another backslash. That escaping is the\nrequisite procedure for embedding one JSON structure inside another.\n\n\nNote that the Swagger UI can't currently be used to pass a body.\n\nPlease also note that this endpoint should be considered beta and\nmay change or disappear in the future. That is the reason for the\ndeprecation.\n", |
2501 | 2501 | "tags": [ |
2502 | 2502 | "Index" |
2503 | 2503 | ], |
|
8533 | 8533 | "Manifests" |
8534 | 8534 | ], |
8535 | 8535 | "summary": "Initiate the preparation of a manifest", |
8536 | | - "description": "\nCreate a manifest preparation job, returning either\n\n- a 301 redirect to the URL of the status of that job or\n\n- a 302 redirect to the URL of an already prepared manifest.\n\nThis endpoint is not suitable for interactive use via the\nSwagger UI. Please use [PUT /fetch/manifest/files][1] instead.\n\n[1]: #operations-Manifests-put_fetch_manifest_files\n\nAny of the query parameters documented below can alternatively be passed\nas a property of a JSON object in the body of the request. This can be\nuseful in case the value of the `filters` query parameter causes the URL\nto exceed the maximum length of 8192 characters, resulting in a 413\nRequest Entity Too Large response.\n\nThe request `PUT /manifest/files?filters={\u2026}`, for example, is equivalent to `PUT /manifest/files`\nwith the body `{\"filters\": \"{\u2026}\"}` in which any double quotes or\nbackslash characters inside `\u2026` are escaped with another backslash. That\nescaping is the requisite procedure for embedding one JSON structure\ninside another.\n", |
| 8536 | + "description": "\nCreate a manifest preparation job, returning either\n\n- a 301 redirect to the URL of the status of that job or\n\n- a 302 redirect to the URL of an already prepared manifest.\n\nThis endpoint is not suitable for interactive use via the\nSwagger UI. Please use [PUT /fetch/manifest/files][1] instead.\n\n[1]: #operations-Manifests-put_fetch_manifest_files\n\nAny of the query parameters documented below can alternatively be passed\nas a property of a JSON object in the body of the request. This is\nreferred to as *parameter hoisting* and can be useful in case the value\nof the `filters` query parameter causes the URL to exceed the maximum\nlength of 8192 characters, resulting in a 413 Request Entity Too Large\nresponse.\n\nThe request `PUT /manifest/files?filters={\u2026}`, for example, is equivalent to `PUT /manifest/files`\nwith a `Content-Type` header of `application/json` and the body\n`{\"filters\": \"{\u2026}\"}` in which any double quotes or backslash characters\ninside `\u2026` are escaped with another backslash. That escaping is the\nrequisite procedure for embedding one JSON structure inside another.\n", |
8537 | 8537 | "parameters": [ |
8538 | 8538 | { |
8539 | 8539 | "name": "catalog", |
|
9995 | 9995 | "Manifests" |
9996 | 9996 | ], |
9997 | 9997 | "summary": "Initiate the preparation of a manifest via XHR", |
9998 | | - "description": "\nCreate a manifest preparation job, returning a 200 status\nresponse whose JSON body emulates the HTTP headers that would be\nfound in a response to an equivalent request to the [PUT\n/manifest/files][1] endpoint.\n\nWhenever client-side JavaScript code is used in a web\napplication to request the preparation of a manifest from Azul,\nthis endpoint should be used instead of [PUT\n/manifest/files][1]. This way, the client can use XHR to make\nthe request, retaining full control over the handling of\nredirects and enabling the client to bypass certain limitations\non the native handling of redirects in web browsers. For\nexample, most browsers ignore the `Retry-After` header in\nredirect responses, causing them to prematurely exhaust the\nupper limit on the number of consecutive redirects, before the\nmanifest generation job is done.\n\n[1]: #operations-Manifests-put_manifest_files\n\nAny of the query parameters documented below can alternatively be passed\nas a property of a JSON object in the body of the request. This can be\nuseful in case the value of the `filters` query parameter causes the URL\nto exceed the maximum length of 8192 characters, resulting in a 413\nRequest Entity Too Large response.\n\nThe request `PUT /fetch/manifest/files?filters={\u2026}`, for example, is equivalent to `PUT /fetch/manifest/files`\nwith the body `{\"filters\": \"{\u2026}\"}` in which any double quotes or\nbackslash characters inside `\u2026` are escaped with another backslash. That\nescaping is the requisite procedure for embedding one JSON structure\ninside another.\n", |
| 9998 | + "description": "\nCreate a manifest preparation job, returning a 200 status\nresponse whose JSON body emulates the HTTP headers that would be\nfound in a response to an equivalent request to the [PUT\n/manifest/files][1] endpoint.\n\nWhenever client-side JavaScript code is used in a web\napplication to request the preparation of a manifest from Azul,\nthis endpoint should be used instead of [PUT\n/manifest/files][1]. This way, the client can use XHR to make\nthe request, retaining full control over the handling of\nredirects and enabling the client to bypass certain limitations\non the native handling of redirects in web browsers. For\nexample, most browsers ignore the `Retry-After` header in\nredirect responses, causing them to prematurely exhaust the\nupper limit on the number of consecutive redirects, before the\nmanifest generation job is done.\n\n[1]: #operations-Manifests-put_manifest_files\n\nAny of the query parameters documented below can alternatively be passed\nas a property of a JSON object in the body of the request. This is\nreferred to as *parameter hoisting* and can be useful in case the value\nof the `filters` query parameter causes the URL to exceed the maximum\nlength of 8192 characters, resulting in a 413 Request Entity Too Large\nresponse.\n\nThe request `PUT /fetch/manifest/files?filters={\u2026}`, for example, is equivalent to `PUT /fetch/manifest/files`\nwith a `Content-Type` header of `application/json` and the body\n`{\"filters\": \"{\u2026}\"}` in which any double quotes or backslash characters\ninside `\u2026` are escaped with another backslash. That escaping is the\nrequisite procedure for embedding one JSON structure inside another.\n", |
9999 | 9999 | "parameters": [ |
10000 | 10000 | { |
10001 | 10001 | "name": "catalog", |
|
0 commit comments