JSONAPI-Resources / JSONAPI-Resources/jsonapi-resources
Cross namespace relationships
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Ruby
- Sterne
- 2.3k
- Forks
- 546
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
The problem:
Right now namespaces are assumed to be used for versioning, though they could also be used for separating entire sets of resources in isolated namespaces. JR does not currently support resource relationships which cross namespaces. #893 attempts to solve this, but as I brought up in the comments there is the potential for the system to encounter a situation where the correct behavior is ambiguous or will be inconsistent depending on the order of serialization.
Proposal:
A simple set of resource resolution rules could be used to solve this issue without the need to specifically mark up relationships definitions on a resource.
Rules:
- All resource resolution will take place relative to the namespace of the request ("Request Namespace").
- Related resources will be assumed to be in the Request Namespace.
- Resource definitions will support a new method called
global_resourcewhich will register a resource type in a "Global Resource Map" to this resource class. - Declaring two resources classes with the same type as
global_resourcewill raise an exception or emit a warning, which should catch conflicts during development. - If a resource class does not exist in the Request Namespace the Global Resource Map will be consulted for the resource class.
- Resources created from the Global Resource Map will still follow same resolution rules starting with the Request Namespace. In other words relationships in a global resource will first resolve based on the Request Namespace.
I believe these rules should allow unambiguous resolution of resources and prevent runtime issues where a resource is serialized with differing sets of rules (resource definitions), and meet the intent of #893.
Let's discuss this and other proposals here. I haven't tried to code this, but I think it's possible to modify the code to support these rules without a lot of refactoring. If you see potential road blocks in either this project or your projects please raise them here.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Es werden keine Dateien, Tests oder Einstiegspunkte genannt. Überprüfe zunächst das bestehende Verhalten von Namespaces und der Auflösung von Beziehungen sowie die Diskussion rund um #893. Kläre anschließend die Auflösungsregeln und definiere Tests, die ein eindeutiges Verhalten über Namespaces hinweg vor der Implementierung demonstrieren.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- ruby
- Bereich
- api, backend-api-design
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Muss geklärt werden
- Anfängerfreundlichkeit
- 25/100