You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<aname="openrpc-methods"></a>methods | [[Method Object](#method-object)\|[Reference Object](#reference-object)] | **REQUIRED**. The available methods for the API. While it is required, the array may be empty (to handle security filtering, for example).
Holds a set of reusable objects for different aspects of the OpenRPC.
All objects defined within the components object will have no effect on the API unless they are explicitly referenced from properties outside the components object.
Field Name | Type | Description
---|:---|---
<aname="components-content-descriptors"></a>contentDescriptors | Map[`string`, [Content Descriptor Object](#content-descriptor-object)] | An object to hold reusable [Content Descriptor Objects](#content-descriptor-object).
<aname="components-schemas"></a>schemas | Map[`string`, [Schema Object](#schema-object)] | An object to hold reusable [Schema Objects](#schema-object).
<aname="components-examples"></a>examples | Map[`string`, [Example Object](#example-object)] | An object to hold reusable [Example Objects](#example-object).
<aname="components-links"></a> links | Map[`string`, [Link Object](#link-object)] | An object to hold reusable [Link Objects](#link-object).
<aname="components-errors"></a>errors | Map[`string`, [Error Object](#error-object)] | An object to hold reusable [Error Objects](#error-object).
<aname="components-example-pairing-objects"></a>examplePairingObjects | Map[`string`, [Example Pairing Object](#example-pairing-object)] | An object to hold reusable [Example Pairing Objects](#example-pairing-object).
<aname="components-tags"></a>tags | Map[`string`, [Tag Object](#tag-object)] | An object to hold reusable [Tag Objects](#tag-object).
I think this would be a thing for the new linter we've been working on as a case which would be a no-duplicates , I think spec reference just makes everything easier once you have larger spec, but cautions make sense . @shanejonas looping for a feature for the linter.
Otherwise I'm not sure why we wouldn't support refs
To clarify, what I mean is that the components object itself doesn't support methods. That is, if I had a Method to stick in the components object, there is nowhere for me to put it
Activity
github-actions commentedon Jun 10, 2024
Welcome to OpenRPC! Thank you for taking the time to create an issue. Please review the guidelines
aatifsyed commentedon Jun 11, 2024
Relevant comment: #339 (comment)
aatifsyed commentedon Jun 11, 2024
Possible that this shouldn't be allowed, since it'd allow you to trivially create duplicate methods, and if not, then... why have them in
components?zcstarr commentedon Jul 27, 2025
I think this would be a thing for the new linter we've been working on as a case which would be a no-duplicates , I think spec reference just makes everything easier once you have larger spec, but cautions make sense . @shanejonas looping for a feature for the linter.
Otherwise I'm not sure why we wouldn't support refs
aatifsyed commentedon Jul 28, 2025
To clarify, what I mean is that the components object itself doesn't support methods. That is, if I had a
Methodto stick in the components object, there is nowhere for me to put itzcstarr commentedon Aug 8, 2025
Yeah I think the question is when would you share or reuse a method component? Is it mostly centered around a notion of completeness ?
aatifsyed commentedon Aug 8, 2025
You'll have to ask the authors of the spec, since it's spec wording, not mine :)
The fix is either:
or
+ OpenRPC.components.methods: Map[string, Method]aatifsyed commentedon Aug 8, 2025
@BelfordZ in case you want to weigh in