fixes #266: Replace list of REST API clients with OpenAPI instructions

[guusdk]

The listed client implementations were partially implemented and mostly unmaintained. Instead of pointing to these, the documentation now suggests generating a client from the OpenAPI specification that the plugin publishes.

Summary by CodeRabbit

• Documentation
  • Replaced the list of REST API client libraries with instructions for generating a client from the plugin’s OpenAPI specification.
  • Added links to the YAML and JSON specifications and noted where to find interactive documentation in the Openfire admin console.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: a459bcc0-ec85-4fbb-bff2-d6b4c1f0b5f8

📥 Commits

Reviewing files that changed from the base of the PR and between 35a943d and 6bb8400.

📒 Files selected for processing (3)

• changelog.html
• readme.html
• readme.md

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The README replaces REST API client library lists with instructions for generating clients from the plugin’s OpenAPI specification. The 1.12.1 changelog records the documentation change.

Changes

REST API client documentation

Layer / File(s)	Summary
Client generation documentation readme.md, readme.html, changelog.html	The README documents the YAML and JSON specification URLs and the interactive documentation link in the Openfire admin console. The HTML table of contents links to the new section. The changelog records the change.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~3 minutes

Change: Other

Suggested reviewers: fishbowler

Merge Risk: ⚪ Minimal · up to 6bb84

The documentation now points users to the plugin's OpenAPI specification for generating clients instead of listing unmaintained libraries. API behavior is unchanged, and no merge-blocking risk remains.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 6bb84

The new client-generation instructions include an unencrypted URL that can require an administrator password or API secret. Similar HTTP examples were already documented, and the alternative YAML URL does not require credentials under the default configuration, which limits the added risk.

Retained concerns

• High · security · inferred: The new client-generation instructions offer an HTTP JSON specification URL that, under the default authentication filter, requires an administrator credential or shared secret in the Authorization header. Fetching it over an untrusted connection can disclose that credential. This is an added documented workflow, not a new server authentication boundary; prior README examples already paired HTTP REST URLs with Authorization headers.

Security review details

Security Blast Radius

• inferred — The relevant exposure is to a party able to observe a reader’s HTTP connection to the REST plugin. A disclosed Basic credential may carry Openfire administrator authority; a disclosed shared secret carries the plugin’s REST API authority. The PR does not change those authorities or the server routes.

Security Findings and Attack Paths

• observed — A retained, reportable sensitive-data-exposure finding is anchored to the new HTTP specification examples.
• inferred — A reader who fetches the documented JSON specification over HTTP using the default authentication flow can transmit an administrator credential or shared secret without transport encryption. The YAML route’s default authentication bypass is counterevidence to assuming that both documented downloads require credentials.

Trust Boundaries and Controls

• observed — The existing REST resource registration uses an authentication filter, with a configurable custom-filter alternative. The generated specification’s security declaration describes authentication; it is not itself evidence that a request was authenticated or encrypted.

Hardening Proposals

• proposed — Use HTTPS in the specification examples and state that credential-bearing specification requests and generated-client traffic should use an encrypted connection.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main documentation change: replacing the REST API client list with OpenAPI generation instructions. It also references the related issue.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[guusdk]

@Redor this implies archiving the https://github.com/igniterealtime/REST-API-Client project, which is marked as 'official', but seems to be unmaintained. What do you think?