brk_server
HTTP server providing REST API access to Bitcoin analytics data
brk_server provides a high-performance HTTP server that exposes BRK's indexed blockchain data and computed analytics through a comprehensive REST API. It offers multiple output formats, intelligent caching, compression, and optional web interface serving.
URL: https://bitview.space/api
What it provides
- REST API: Vector-based data access with flexible querying and pagination
- Multiple Output Formats: JSON, CSV, TSV, and Markdown table formatting
- Performance Features: ETag caching, compression, and request weight limiting
- Web Interface: Optional static file serving for web applications
- MCP Integration: Model Context Protocol support for LLM integration
Key Features
API Capabilities
- Direct vector access: Single vector queries with index-to-ID pattern
- Multi-vector queries: Query multiple datasets simultaneously
- Flexible pagination: Positive/negative indexing with range queries
- Format negotiation: Multiple output formats based on use case
Performance Features
- ETag caching: Conditional requests with 304 Not Modified responses
- Compression: Brotli, Gzip, Zstd, Deflate support with automatic negotiation
- Request weight limiting: Protects against oversized queries (max 320,000 weight)
- In-memory caching: 10,000-item cache with 50ms guard timeout
HTTP Features
- Auto port assignment: Starts from port 3110, increments if busy
- CORS enabled: Cross-origin requests for web clients
- Tracing middleware: Colored request/response logging
- Static file serving: Optional website hosting
Usage
Basic Server Setup
use Server;
use Interface;
use Indexer;
use Computer;
// Load data sources
let indexer = forced_import?;
let computer = forced_import?;
// Create interface and server
let interface = build;
let server = new;
// Start server (with MCP support)
server.serve.await?;
API Access Patterns
Single Vector Queries
# Latest 100 price values
# First 50 difficulty values as CSV
# Range from block 800,000 to 800,100
Multi-Vector Queries
# Multiple price metrics for last 30 days
# Block statistics for specific range
# Weekly analytics as JSON matrix
API Reference
Vector Metadata Endpoints
| Endpoint | Description |
|---|---|
GET /api/vecs/index-count |
Total number of available indexes |
GET /api/vecs/id-count |
Total number of vector IDs |
GET /api/vecs/vec-count |
Total vectors (all index/ID combinations) |
GET /api/vecs/indexes |
List of all available indexes |
GET /api/vecs/accepted-indexes |
Mapping of indexes to accepted variants |
GET /api/vecs/ids?page=N |
Paginated vector IDs (1000/page) |
GET /api/vecs/index-to-ids?index=INDEX&page=N |
IDs supporting given index |
GET /api/vecs/id-to-indexes?id=ID |
Indexes supported by given ID |
Vector Data Access
Direct Access Pattern
GET /api/vecs/{INDEX}-to-{ID}
# Examples
Multi-Vector Query
GET /api/vecs/query
Required Parameters:
index: Vector index type (height, date, week, month, etc.)ids: Comma or space-separated vector IDs
Optional Parameters:
from(i64): Start index (negative = from end, default: 0)to(i64): End index (exclusive, negative = from end)count(usize): Maximum number of resultsformat: Output format (json,csv,tsv,md)
Response Types
Single Value (one vector, one result):
42.5
Array (one vector, multiple results):
Matrix (multiple vectors):
CSV Format:
index,close,supply,fee_rate
0,42.5,1500,0.05
1,43.1,1520,0.052
2,44.2,1480,0.048
System Endpoints
| Endpoint | Description |
|---|---|
GET /version |
Server version information |
GET /health |
Health check with timestamp |
GET /api |
API documentation redirect |
GET /* |
Static file serving (if enabled) |
Configuration
Server State
Middleware Stack
- Compression Layer: Brotli, Gzip, Zstd, Deflate
- Response URI Layer: Adds URI to response extensions for logging
- Trace Layer: Request/response logging with colored output
Caching Strategy
- ETag generation: Based on data content and query parameters
- Conditional requests: 304 Not Modified for unchanged data
- In-memory cache: 10,000 items with LRU eviction
- Cache headers:
Cache-Control: must-revalidate
Performance Characteristics
Request Weight System
- Weight calculation: Based on data range size and complexity
- Weight limit: 320,000 units per request
- Protection: Prevents oversized queries that could impact performance
Compression
- Automatic negotiation: Based on
Accept-Encodingheader - Multiple algorithms: Brotli (best), Zstd, Gzip, Deflate
- Transparent: Applied automatically to all responses
Logging
- Colored output: Green for 200, red for errors, gray for redirects
- Request timing: Latency measurement and display
- Status tracking: HTTP status codes with appropriate colors
Dependencies
axum- High-performance async web frameworktower-http- HTTP middleware (compression, tracing, CORS)brk_interface- Data access and formatting layerbrk_mcp- Model Context Protocol routesquick_cache- Fast in-memory cachingtokio- Async runtime for networking
This README was generated by Claude Code