Guides

REST API Basics

This page covers the basic of interacting with and consuming the View REST API.

Suggest Edits

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 deployment
  • port: Specific to each microservice (see Microservices section)
  • apiversion: In the format vx.y (e.g., v1.0, v2.0)
  • tenant-guid: Identifies the tenant within the multi-tenant system
  • resource-type: Specifies the type of resource being accessed
  • resource-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:

  1. View Storage Server (Ports: 8001, 8002)

    • Native REST API: 8001
    • S3 API: 8002
    • Purpose: Create repositories (buckets) and manage objects

  2. View Crawler (Port: 8101)

    • Connects to existing data repositories (file, NFS, CIFS, S3, Azure BLOB)

  3. View Lexi (Port: 8201)

    • Data catalog and metadata/semantic search platform

  4. View Embeddings (Port: 8301)

    • Generates embeddings, converting semantic cells and chunks to vector form

  5. View Vector (Port: 8311)

    • Vector storage engine using Postgres pgvector
    • Stores various metadata attributes

  6. View UDR Generator (Port: 8321)

    • Generates metadata and features from source documents

  7. View Orchestrator (Port: 8501)

    • Function-as-a-Service (FaaS) platform for running processing pipeline steps

  8. View Configuration Server (Port: 8601)

    • Overall configuration and management of the deployment

  9. 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 18 days ago