Skip to content

SY-3764: Support HTTP devices in Driver#1993

Merged
pjdotson merged 148 commits intorcfrom
sy-3764-support-http-devices-in-driver
Feb 20, 2026
Merged

SY-3764: Support HTTP devices in Driver#1993
pjdotson merged 148 commits intorcfrom
sy-3764-support-http-devices-in-driver

Conversation

@pjdotson
Copy link
Contributor

@pjdotson pjdotson commented Feb 13, 2026

Issue Pull Request

Linear Issue

SY-3764

Description

Support HTTP devices in the Driver by adding a mock HTTP server, and support for device configuration and connection.

Basic Readiness

  • I have performed a self-review of my code.
  • I have added relevant, automated tests to cover the changes.
  • I have updated documentation to reflect the changes.

Greptile Overview

Greptile Summary

Added comprehensive HTTP device support to the Driver framework, enabling HTTP-based device integration alongside existing protocols like Modbus and EtherCAT.

Major changes:

  • Implemented driver::http::device::Client using libcurl with support for all HTTP methods, multiple authentication schemes (bearer token, basic auth, API key), custom headers, and SSL verification
  • Added mock HTTP server using cpp-httplib for testing with route registration, request logging, and HTTPS support
  • Created base64 encoding/decoding utilities needed for HTTP basic authentication
  • Registered HTTP factory in driver rack integration system
  • Included BoringSSL as a new dependency for SSL/TLS support
  • Renamed JSONFile::open to JSONFile::open_file (likely to avoid name conflicts with new open function from HTTP libraries)
  • Added comprehensive test coverage for all HTTP functionality

The implementation is well-structured with proper error handling, efficient multi-handle support for parallel requests, and pre-configured curl handles to minimize hot-path overhead.

Confidence Score: 5/5

  • This PR is safe to merge with very low risk
  • The implementation is thorough with comprehensive test coverage (1450+ lines of device tests, 400+ lines of server tests), proper error handling throughout, well-structured code following existing patterns, and no critical issues found. The HTTP factory is currently a stub (returns empty/null) which safely prevents premature usage in production. All changes are additive with minimal impact on existing code.
  • No files require special attention

Important Files Changed

Filename Overview
driver/http/device/device.cpp Added HTTP client implementation using libcurl with multi-handle support for parallel requests, authentication (bearer/basic/API key), and SSL verification
driver/http/device/device.h Defined HTTP device interfaces including ConnectionConfig, AuthConfig, RequestConfig, Response, and Client class for making HTTP requests
driver/http/mock/server.cpp Implemented mock HTTP server using cpp-httplib for testing with route registration, request logging, and SSL support
x/cpp/base64/base64.cpp Implemented standard base64 encoding and decoding using lookup tables
driver/http/factory.cpp Added stub HTTP factory implementation (configure_task and configure_initial_tasks return empty/null)
driver/rack/factories.cpp Registered HTTP factory in the driver rack integration list

Class Diagram

classDiagram
    class Client {
        -ConnectionConfig config_
        -void* multi_handle_
        -vector~Handle~ handles_
        +make(config, requests) pair~Client, Error~
        +request(bodies) pair~vector~Response~, Error~
    }
    
    class ConnectionConfig {
        +string base_url
        +uint32_t timeout_ms
        +AuthConfig auth
        +map~string,string~ headers
        +bool verify_ssl
    }
    
    class AuthConfig {
        +string type
        +string token
        +string username
        +string password
        +string header
        +string key
    }
    
    class RequestConfig {
        +Method method
        +string path
        +map~string,string~ query_params
        +map~string,string~ headers
        +string response_content_type
        +string request_content_type
    }
    
    class Response {
        +int status_code
        +string body
        +TimeRange time_range
    }
    
    class Handle {
        -CURL* handle
        -curl_slist* headers
        -string response_body
        -bool accepts_body
        -string expected_content_type
        -CURLcode result_code
    }
    
    class Server {
        -unique_ptr~Impl~ impl_
        +start() Error
        +stop()
        +base_url() string
        +received_requests() vector~ReceivedRequest~
    }
    
    class Factory {
        +name() string
        +configure_task() pair~Task, bool~
        +configure_initial_tasks() vector~pair~Task, Task~~
    }
    
    Client --> ConnectionConfig : uses
    Client --> RequestConfig : uses
    Client --> Handle : contains
    Client --> Response : returns
    ConnectionConfig --> AuthConfig : contains
    Server --> ReceivedRequest : logs
    Factory --|> task__Factory : implements
Loading

Last reviewed commit: 38ad3e2

pjdotson and others added 30 commits February 3, 2026 21:21
This RFC documents the design for integrating an HTTP driver into the
Synnax Driver system, enabling REST API polling and control capabilities.

Key features:
- Read Tasks: Poll HTTP endpoints and write JSON data to Synnax channels
- Write Tasks: Send HTTP requests based on Synnax channel values
- Scan Tasks: Health monitoring of HTTP endpoints
- Type conversion between JSON and Synnax data types
- Support for authentication (none, API key, basic, bearer)

The specification includes configuration schemas, implementation details,
Python client API, integration testing approach, and a 19-PR delivery plan
organized by feature (Device → Read → Write → Scan).

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@pjdotson pjdotson merged commit df4be1c into rc Feb 20, 2026
39 checks passed
@pjdotson pjdotson deleted the sy-3764-support-http-devices-in-driver branch February 20, 2026 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants