https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201502/msg00006.html
Hi guys,
I’m new to this list and to working with the API so please tell me if there is another place I should post this.
I may be missing something completely obvious, but I’ve hit a problem.
I’m trying to understand how I can source the metadata about the API in order to write a GUI client which constructs itself based on the metadata it sees. That way my client is only dependent on the structure of the API and doesn’t need to carry any semantics of the API itself, and so I can extend the API without having to write any new GUI code.
So, the obvious way to do this seems to be for the platform_endpoints resource to carry the metadata for the entire domain. However, the metadata is present in the type_definitions_uri of the platform Resource, which causes a couple of problems.
• The platform resource has a one-to-many relation with the platform_endpoints resource, so the platform_endpoints’ metadata sourced from the set of platforms is potentially ambiguous.
• The platform is behind authentication and the platform_endpoints resource potentially isn’t
• If we extend the platform_endpoints resource the only way we can retrieve the metadata is from a platform that knows about that extension. This breaks the loose coupling across the parent-child relation afforded by the Links (which is really nice, by the way)
I can see that there is a problem with versioning of metadata and the Platforms need to run with different versions and this may be why you’ve done it this way. However, I can’t see a way of dealing with the three problems above without extending the API – and making my GUI dependent on that extension being present, which kind-of defeats the point.
The specific extension I have been looking at involves carrying the metadata of the Resource into their corresponding List resources (e.g. putting the metadata for the platform_endpoint into the platform_endpoints resource).
Any help with this would be appreciated.
Thanks,
Mike