Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Restrict POST /v3/service_plans/:guid/visibility to only support appending orgs (and not changing visibility type)

Offen
  • Stimmt etwas nicht?
#4,606 0 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Ein zugehöriger Pull Request wurde bereits gemerged.

  • #4609 von @philippthun — gemerged

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
ruby
Bereich
api

Rechercherichtung

Beginne bei den Einstiegspunkten POST /v3/service_plans/:guid/visibility und PATCH /v3/service_plans/:guid/visibility und vergleiche, wie jeder davon Sichtbarkeitstypen und Organisationszuordnungen behandelt. Die Aufgabe ist abgeschlossen, wenn POST nur Organisationssichtbarkeit für Pläne akzeptiert, die diesen Typ bereits verwenden, während PATCH weiterhin für die Änderung des Sichtbarkeitstyps zuständig ist und ungültige POST-Anfragen einen geeigneten Fehler zurückgeben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Summary

The current implementation of POST /v3/service_plans/:guid/visibility is somewhat inconsistent with REST semantics and allows operations beyond simply appending organizations. Specifically, it can also change the visibility type (e.g., to public or admin), which overlaps with the semantics of PATCH /v3/service_plans/:guid/visibility.

Problem

From a REST perspective:

  • POST should be used to add new resources or associations (in this case, adding orgs to an existing visibility list).
  • PATCH should be used to modify existing state (e.g., changing the visibility type to public or admin).

Currently, POST behaves more like a PATCH, as it allows changing the visibility type, not just appending orgs. This blurs the intended semantics and increases the risk of accidental type changes when clients are only trying to add organizations.

Proposed Change

I propose tightening the semantics of POST /v3/service_plans/:guid/visibility:

  • Allow POST only when type = organization.
  • Ensure the target plan already has visibility type organization. If the plan’s visibility type is not organization, the request should fail with an appropriate error (e.g., 422 Unprocessable Entity).

This ensures that:

  • POST is used solely for appending organizations to organization-scoped plans.
  • PATCH remains the correct method for changing the visibility type.
Compatibility / Migration

This change could break existing clients that currently use POST to modify visibility type. However, those clients can simply switch to using PATCH, which already supports the same behavior. This aligns both endpoints with clearer REST semantics going forward.

Vorherrschende Sprache
Ruby
Sterne
207
Forks
373
Ø Merge
3 T. 2 Std.
Gemergte PRs (30 T.)
69

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cloudfoundry/cloud_controller_ng

Alle Issues in cloudfoundry/cloud_controller_ng

Ähnliche Issues

Weitere Issues zu Ruby

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.