[Task] Define the client-admin registration protocol compatibility contract
- Dominant language
- Java
- Stars
- 8.8k
- Forks
- 3.1k
- Avg merge
- 7d 1h
- Merged PRs (30d)
- 85
Description
### Description
## Background
After splitting Java client modules into `shenyu-client-java`, the client repo and main ShenYu repo must remain compatible through stable registration protocols rather than shared source code.
We need an explicit compatibility contract for client registration, heartbeat, discovery instance registration, and MCP registration.
## Tasks
- [ ] List all client-to-admin registration endpoints.
- [ ] Document request and response fields for each endpoint.
- [ ] Document beat/heartbeat payload and lifecycle behavior.
- [ ] Document discovery instance registration payload and lifecycle behavior.
- [ ] Document MCP registration endpoint `/shenyu-client/register-mcp`.
- [ ] Identify fields that are required, optional, deprecated, or newly added.
- [ ] Define compatibility rules for additive fields, removed fields, and default values.
- [ ] Define how old clients should behave with new admin versions.
- [ ] Define how new clients should behave with old admin versions.
## Expected Output
A protocol compatibility document covering:
- HTTP paths
- DTO fields
- Required/optional field semantics
- Backward compatibility rules
- Forward compatibility rules
- Error handling expectations
- Version compatibility notes
## Acceptance Criteria
- The document is specific enough to guide both main repo and client repo changes.
- Existing registration flows are covered.
- Future protocol changes can be reviewed against this document.
### Task List
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the existing client-to-admin registration, heartbeat, discovery instance, and MCP flows across the main repository and client repository, including /shenyu-client/register-mcp. Record the HTTP paths, DTO fields, lifecycle behavior, compatibility rules, error handling, and version notes; done means the document covers existing flows and guides future changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100