Skip to content

Update Devportal API Spec#2046

Open
ShakyaPr wants to merge 1 commit into
wso2:mainfrom
ShakyaPr:devportal_spec_change
Open

Update Devportal API Spec#2046
ShakyaPr wants to merge 1 commit into
wso2:mainfrom
ShakyaPr:devportal_spec_change

Conversation

@ShakyaPr

Copy link
Copy Markdown
Contributor

Purpose

  • Restructures the Devportal API Spec devportal-openapi-spec-v1.yaml with below things:
    • New URL shape for org-scoped resources: /o/{orgId}/devportal/v1/{resource} (was /devportal/organizations/{orgId}/{resource})
    • Naming normalization — kebab-case resources, consistent camelCase path params, Api casing in operationIds.
    • Subscription-policies lookup redesign — name lookup is now a collection filter, not an overloaded path segment.

URL shape

  • servers.url is now https://devportal.api-platform.io (prod) plus the local HTTP/HTTPS variants. The /devportal base path is gone from servers.url and reintroduced after {orgId} in each path.
  • All org-scoped paths rewritten: /organizations/{orgId}/X/o/{orgId}/devportal/v1/X (~50 paths).
  • Org-collection meta endpoints (POST /organizations, GET/PATCH/DELETE /organizations/{orgId}) kept at the root — they manage the org collection itself, not resources within an org.
  • Non-org paths (/login, /temp-arazzo-file, /applications/*) untouched; these will be dropped from the spec in a follow-up when the legacy-only routes are removed.

Naming changes

Before After
/identityProvider (singular, camelCase) /identity-providers (plural, kebab)
/events, /events/{eventId} /webhook-events, /webhook-events/{eventId}
/deliveries/{deliveryId}/retry /webhook-deliveries/{deliveryId}/retry
{subscriptionId} (1 path, 1 param ref) {subId} — consolidated on existing SubId component
{name} (view name, 3 paths) {viewName} — consolidated on existing ViewName component
{policyIdOrName} (overloaded) {policyId} (see subscription policies redesign)

Component cleanup: removed unused Name and duplicate SubscriptionId parameter components; renamed PolicyIdOrNamePolicyId.

OperationIds normalized so API is rendered as Api (14 IDs across API metadata, API content, API flows): e.g. createAPIMetadatacreateApiMetadata, getAPIFlowgetApiFlow. The PUT API-content endpoint is renamed from updateAPIContent to replaceApiContent to better reflect its replace-semantics. OAuth* operationIds left as-is (proper noun).

Subscription policies — lookup-by-name redesign

  • The old {policyIdOrName} path overloaded one segment to mean either UUID or name (with GET/DELETE interpreting it differently). Replaced with the standard REST split:

    • GET /subscription-policies — new listSubscriptionPolicies operation with optional ?name= filter. Returns an array (0 or 1 item when filtered). New SubscriptionPolicyListResponse component added.
    • GET /subscription-policies/{policyId} — ID-only, single-resource fetch.
    • DELETE /subscription-policies/{policyId} — ID-only, single-resource delete.
      Callers that only have a name now do list?name=X then operate on the returned policyId. New endpoint will need a matching controller method when the spec-driven router is enabled.

@coderabbitai

coderabbitai Bot commented May 29, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@ShakyaPr, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 50 minutes and 29 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: bb266822-6996-4de1-9635-19692d08fa30

📥 Commits

Reviewing files that changed from the base of the PR and between 7821530 and 45a6d33.

📒 Files selected for processing (1)
  • portals/developer-portal/docs/devportal-openapi-spec-v1.yaml
📝 Walkthrough

Walkthrough

This PR implements two coordinated changes: (1) restructures the OpenAPI specification to consolidate organization-scoped resources under a unified /o/{orgId}/devportal/v1 routing pattern, standardizes operation ID naming conventions to consistent *Api* and *Flow* casing, updates subscription policy routing to use strict policyId parameters, and adds corresponding schema definitions; and (2) introduces a multipart file handling middleware (adaptMultipart) that normalizes multer output into the legacy format expected by existing services and integrates it across multiple file upload endpoints in API metadata, application, organization, identity provider, and subscription policy handlers.

Suggested reviewers

  • senthuran16
  • lasanthaS
  • renuka-fernando
  • pubudu538
  • ashera96
  • RakhithaRR
🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check ❓ Inconclusive The title 'Update Devportal API Spec' is vague and generic, using a non-specific verb ('Update') that does not convey the scope, nature, or significance of the changes. Provide a more descriptive title that highlights the main change, such as 'Restructure Devportal API spec: new URL shape, naming normalization, and subscription-policies redesign' or similar.
✅ Passed checks (3 passed)
Check name Status Explanation
Description check ✅ Passed The pull request description comprehensively addresses Purpose, Goals, and Approach sections with clear explanations and examples, but lacks required sections such as Automation tests, Security checks, Samples, Test environment, and related PR/documentation links.
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.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
portals/developer-portal/docs/devportal-openapi-spec-v1.yaml (2)

686-715: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Migrate subscription policy delete/get callers to policyId semantics.

Line 686 changes the contract to {policyId} for lookup/delete. Current integrations still include name-based delete usage (for example, portals/developer-portal/src/routes/devportalRoute.js:103 and platform-api/src/internal/client/devportal_client/subscription_policies_service.go:68-95).

Update callers/routes to use policyId consistently, or temporarily keep a deprecated name-based delete contract during migration.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@portals/developer-portal/docs/devportal-openapi-spec-v1.yaml` around lines
686 - 715, The OpenAPI changed the delete/get path to use {policyId}
(operationId: getSubscriptionPolicy and deleteSubscriptionPolicy) but existing
callers still pass a name; update all callers to use the new policyId semantics
(e.g., change the route usage in
portals/developer-portal/src/routes/devportalRoute.js and the client calls in
platform-api/src/internal/client/devportal_client/subscription_policies_service.go
to send policyId instead of name), or if immediate migration is risky add a
temporary backward-compatible handler in the subscription policies server that
accepts the name-based parameter and resolves it to policyId before delegating
to the existing deleteSubscriptionPolicy/getSubscriptionPolicy logic; ensure
parameter names and generated client calls match the OpenAPI parameter name
policyId.

176-2574: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Align runtime routes with the new org-scoped path contract.

Line 176 starts a broad move to /o/{orgId}/devportal/v1/..., but current route wiring still shows /organizations/:orgId/... patterns (for example, portals/developer-portal/src/routes/devportalRoute.js:100-110). This leaves the published spec ahead of served routes.

Please migrate runtime route registrations in the same release, or keep deprecated legacy paths in the spec until runtime migration is live.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@portals/developer-portal/docs/devportal-openapi-spec-v1.yaml` around lines
176 - 2574, The OpenAPI spec was changed to use the org-scoped path contract
(/o/{orgId}/devportal/v1/...), but runtime route registrations (e.g., in the
devportalRoute router that currently registers routes like
/organizations/:orgId/...) still use the legacy /organizations/:orgId/...
pattern; update the route wiring in the devportalRoute registration (and any
helper that builds route strings) to register the new paths matching the spec,
update middleware/handlers that read the param (orgId vs organizationId) to use
the same param name, run/update route tests, and if backward compatibility is
required add explicit redirects or duplicate legacy routes rather than changing
only the spec.
🧹 Nitpick comments (1)
portals/developer-portal/src/openapi/handlers/_multipart.js (1)

37-43: ⚡ Quick win

Use a null-prototype accumulator for grouped (and ||= is safe on the service’s Node runtime).

grouped is keyed by req.files[*].fieldname; switching from {} to a null-prototype object avoids collisions with inherited properties. The ||= usage is fine since the developer-portal container runs on node:23-bookworm-slim.

♻️ Proposed change
-    const grouped = {};
+    const grouped = Object.create(null);
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@portals/developer-portal/src/openapi/handlers/_multipart.js` around lines 37
- 43, The accumulator object `grouped` is created with a normal object literal
which can inherit properties and cause key collisions when using
`req.files[*].fieldname`; change its initialization to a null-prototype object
(use Object.create(null)) and keep the existing grouping logic inside the loop
(the block that iterates over req.files and uses (grouped[f.fieldname] ||=
[]).push(f)) so keys are stored on a clean map with the same ||= shorthand.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@portals/developer-portal/src/openapi/handlers/_multipart.js`:
- Around line 38-47: The handler currently blocks the event loop by using
fs.readFileSync when f.path is present and also uses a plain object for grouped
that can collide with prototype keys; change the handler to be async and await
fs.promises.readFile(f.path) (or use util.promisify) inside a try/catch and call
next(err) on failures, and replace the grouped plain object with
Object.create(null) or a Map so fieldname keys cannot collide; locate the loop
that iterates req.files and the grouped variable initialization in _multipart.js
(the block that sets f.buffer and pushes into grouped[f.fieldname]) and update
those lines to use asynchronous reads and a safe map-like container while
preserving the existing error routing via next.

---

Outside diff comments:
In `@portals/developer-portal/docs/devportal-openapi-spec-v1.yaml`:
- Around line 686-715: The OpenAPI changed the delete/get path to use {policyId}
(operationId: getSubscriptionPolicy and deleteSubscriptionPolicy) but existing
callers still pass a name; update all callers to use the new policyId semantics
(e.g., change the route usage in
portals/developer-portal/src/routes/devportalRoute.js and the client calls in
platform-api/src/internal/client/devportal_client/subscription_policies_service.go
to send policyId instead of name), or if immediate migration is risky add a
temporary backward-compatible handler in the subscription policies server that
accepts the name-based parameter and resolves it to policyId before delegating
to the existing deleteSubscriptionPolicy/getSubscriptionPolicy logic; ensure
parameter names and generated client calls match the OpenAPI parameter name
policyId.
- Around line 176-2574: The OpenAPI spec was changed to use the org-scoped path
contract (/o/{orgId}/devportal/v1/...), but runtime route registrations (e.g.,
in the devportalRoute router that currently registers routes like
/organizations/:orgId/...) still use the legacy /organizations/:orgId/...
pattern; update the route wiring in the devportalRoute registration (and any
helper that builds route strings) to register the new paths matching the spec,
update middleware/handlers that read the param (orgId vs organizationId) to use
the same param name, run/update route tests, and if backward compatibility is
required add explicit redirects or duplicate legacy routes rather than changing
only the spec.

---

Nitpick comments:
In `@portals/developer-portal/src/openapi/handlers/_multipart.js`:
- Around line 37-43: The accumulator object `grouped` is created with a normal
object literal which can inherit properties and cause key collisions when using
`req.files[*].fieldname`; change its initialization to a null-prototype object
(use Object.create(null)) and keep the existing grouping logic inside the loop
(the block that iterates over req.files and uses (grouped[f.fieldname] ||=
[]).push(f)) so keys are stored on a clean map with the same ||= shorthand.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 140413b5-3f2f-4ef0-a1f7-f7e558d68ab3

📥 Commits

Reviewing files that changed from the base of the PR and between 2280d6a and 7821530.

📒 Files selected for processing (9)
  • portals/developer-portal/docs/devportal-openapi-spec-v1.yaml
  • portals/developer-portal/src/openapi/handlers/_multipart.js
  • portals/developer-portal/src/openapi/handlers/apiContent.js
  • portals/developer-portal/src/openapi/handlers/apis.js
  • portals/developer-portal/src/openapi/handlers/applications.js
  • portals/developer-portal/src/openapi/handlers/identityProviders.js
  • portals/developer-portal/src/openapi/handlers/organizationContent.js
  • portals/developer-portal/src/openapi/handlers/organizations.js
  • portals/developer-portal/src/openapi/handlers/subscriptionPolicies.js

Comment thread portals/developer-portal/src/openapi/handlers/_multipart.js Outdated
@ShakyaPr ShakyaPr force-pushed the devportal_spec_change branch from 7821530 to 45a6d33 Compare May 29, 2026 05:36
"404":
$ref: "#/components/responses/TextMessageResponse"
/organizations/{orgId}/provider:
/o/{orgId}/devportal/v1/provider:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/o/{orgId}/devportal/v1/provider:
/o/{orgId}/devportal/v1/providers:

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