REST API Basics
This page covers the basic of interacting with and consuming the View REST API.
API Basics
Protocol and Deployment
The API platform can be configured to listen on either HTTP or HTTPS, depending on the user's configuration. Since View is deployed on-premises in private networks using Docker, users have control over the hostname and security settings.
By default, View uses HTTP. If you would like to enable HTTPS, configure the nginx-view
instance with your SSL certificate details.
HTTP Methods
View primarily uses the following HTTP methods:
- GET: Retrieve resources
- PUT: Create or update resources
- POST: Perform logic operations
- DELETE: Remove resources
- HEAD: Retrieve resource metadata
Note: While these are the general usage patterns, there may be occasional deviations for specific endpoints.
URL Structure
The general URL structure for View APIs is: `[http||https]://[hostname]:[port]/[apiversion]/tenants/[tenant-guid]/[resource-type]/[resource-guid]
hostname
: Defined by the user based on their deploymentport
: Specific to each microservice (see Microservices section)apiversion
: In the formatvx.y
(e.g.,v1.0
,v2.0
)tenant-guid
: Identifies the tenant within the multi-tenant systemresource-type
: Specifies the type of resource being accessedresource-guid
: Identifies the individual resource
While this is the typical URL structure, deviations do exist, and will be documented accordingly.
Authentication
View uses bearer tokens for authentication. These tokens should be included in the Authorization
header of each request. Tokens are created through the Credential
API within the system, and closely resemble S3's access key and secret key model.
Response Format
Most View APIs return responses in JSON format. The exception is when accessing object data directly or when using the S3 API, which may return object data or XML responses.
Rate Limiting
Requests are rate-limited to 16 per second using nginx. Exceeding this limit will result in a 429 (Too Many Requests) error.
Error Codes
View uses standard HTTP status codes, including:
- 200: OK
- 201: Created
- 204: No Content
- 400: Bad Request
- 401: Unauthorized
- 403: Forbidden
- 404: Not Found
- 409: Conflict
- 429: Too Many Requests
- 500: Internal Server Error
- 501: Not Implemented
- 503: Service Unavailable
Microservices
View consists of several microservices, each serving a specific purpose:
-
View Storage Server (Ports: 8001, 8002)
- Native REST API: 8001
- S3 API: 8002
- Purpose: Create repositories (buckets) and manage objects
-
View Crawler (Port: 8101)
- Connects to existing data repositories (file, NFS, CIFS, S3, Azure BLOB)
-
View Lexi (Port: 8201)
- Data catalog and metadata/semantic search platform
-
View Embeddings (Port: 8301)
- Generates embeddings, converting semantic cells and chunks to vector form
-
View Vector (Port: 8311)
- Vector storage engine using Postgres pgvector
- Stores various metadata attributes
-
View UDR Generator (Port: 8321)
- Generates metadata and features from source documents
-
View Orchestrator (Port: 8501)
- Function-as-a-Service (FaaS) platform for running processing pipeline steps
-
View Configuration Server (Port: 8601)
- Overall configuration and management of the deployment
-
View Semantic Cell Extractor (Port: 8341)
- Identifies and extracts semantic cells and semantic chunks from source documents
Quick Start
To check if a service is operational, you can use a simple cURL command:
curl http://localhost:8001
Updated about 1 month ago