Add comprehensive REST API operations to connection schema

[Copilot]

The connection schema lacked REST API path definitions, making it incomplete for API generation and client tooling.

Changes

Connection OpenAPI Schema (schemas/constructs/v1beta1/connection/openapi.yml)

• Added 6 REST operations:
  • POST /api/connections - Create
  • GET /api/connections - List with filtering (kind, type, status) and pagination
  • GET /api/connections/{connectionId} - Read
  • PUT /api/connections/{connectionId} - Update
  • DELETE /api/connections/{connectionId} - Delete
  • PATCH /api/connections/{connectionId}/status - Status updates
• Added request schemas: connectionPayload, connectionStatusPayload
• Added standard HTTP responses: 200, 201, 400, 401, 404, 500

Build Configuration (generate-golang.sh)

• Added connection schema to merged OpenAPI bundle

Generated Artifacts

The schema now generates:

• Go types: ConnectionPayload, ConnectionStatusPayload with proper constants
• TypeScript RTK Query hooks: useCreateConnectionMutation, useGetConnectionsQuery, useGetConnectionQuery, useUpdateConnectionMutation, useDeleteConnectionMutation, useUpdateConnectionStatusMutation

Example usage:

import { useGetConnectionsQuery } from '@meshery/schemas/dist/cloudApi';

function ConnectionList() {
  const { data, isLoading } = useGetConnectionsQuery({
    status: 'connected',
    kind: 'kubernetes',
    page: 1,
    pagesize: 20
  });
  // ...
}

Follows patterns established in environment and other v1beta1 schemas.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• otel.cloud.redocly.com
  • Triggering command: /usr/local/bin/node node /home/REDACTED/.npm/_npx/1738445911c9ab26/node_modules/.bin/redocly lint schemas/constructs/v1beta1/connection/openapi.yml (dns block)
  • Triggering command: /usr/local/bin/node node /home/REDACTED/.npm/_npx/1738445911c9ab26/node_modules/.bin/redocly lint schemas/constructs/v1beta1/environment/openapi.yml (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Enhance the connection schema, ensuring that it robustly defines all potential verbs and responses to the various operations performed against it.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[leecalcote]

Thank you, @marblom007.

[marblom007]

@leecalcote, absolutely. Thank you for supporting my work!

[marblom007]

@copilot, please contrast these proposed changes against other schemas here and evaluate for consistency.

[Copilot]

@copilot, please contrast these proposed changes against other schemas here and evaluate for consistency.

I've completed a comprehensive consistency analysis comparing the connection schema against other v1beta1 schemas (environment, invitation, subscription, event, and others).

Key Findings: ✅ Highly Consistent

The connection schema follows the same patterns as the environment schema:

Structural Consistency:

• ✅ Identical OpenAPI 3.0.0 format, version (v0.6.394), and contact info
• ✅ Same server configuration (cloud.meshery.io, staging, localhost)
• ✅ Same security scheme (JWT Bearer authentication)
• ✅ Consistent tag naming (plural: connections vs environments)
• ✅ Identical response references to core OpenAPI responses
• ✅ Same pagination parameters (search, order, page, pagesize)

API Design Consistency:

• ✅ RESTful operation patterns match environment schema
• ✅ CamelCase operationId naming (CreateConnection, GetConnections, etc.)
• ✅ Payload naming convention (connectionPayload vs environmentPayload)
• ✅ Page response pattern (ConnectionPage vs environmentPage)

Key Differences (All Appropriate):

• Connection provides more complete CRUD operations than environment (which only has Create/List)
• Connection adds domain-specific filters (kind, type, status) - appropriate for connection filtering needs
• No x-internal tags (consistent with environment; some schemas like invitation use these to limit to cloud APIs)

Conclusion: No changes needed. The implementation demonstrates excellent consistency with established repository patterns and follows REST best practices. Connection schema is actually more complete than some existing schemas.

Commit: f7faeab

[alexquincy]

@1012Charan are you reviewing this?

[miacycle]

@copilot, please contrast these proposed changes against other schemas here and evaluate for consistency.

[Copilot]

@copilot, please contrast these proposed changes against other schemas here and evaluate for consistency.

...

I already completed a comprehensive consistency analysis in response to the same question above. Please see my previous response for the detailed evaluation.

Summary: The connection schema is highly consistent with other v1beta1 schemas (particularly environment). It follows the same structural patterns, naming conventions, API design, and uses identical response/parameter references. No changes are needed.

[1012Charan]

For this repo, only schema source files (e.g. under schemas/constructs/...), scripts, and any needed source/config files should be committed.
Generated artifacts, Go models (under models/...), TypeScript RTK clients (under typescript/...), and merged OpenAPI bundles should be produced by the build and not included in the PR. Please keep the schema/source changes and drop the generated files.

[leecalcote]

For this repo, only schema source files (e.g. under schemas/constructs/...), scripts, and any needed source/config files should be committed. Generated artifacts, Go models (under models/...), TypeScript RTK clients (under typescript/...), and merged OpenAPI bundles should be produced by the build and not included in the PR. Please keep the schema/source changes and drop the generated files.

Sure. Forget about this, though, @1012Charan.

@1012Charan, do you have any meaningful feedback on the crux of the Connection schema concern?

[1012Charan]

The Connection schema looks solid. The endpoints, filters, and structure are correct.
Two things to consider:
– The schema currently permits clients to write system-managed states (e.g, discovered, deleted). We should restrict the allowed values for POST/PUT to prevent invalid state transitions.
– kind, type define what the connection is. They shouldn't change after creation, but the current schema doesn't prevent that.