Today we have the ?export flag that can appear at any level of the hierarchy to ask for a minimized view of the resource(s) being returned. In particular it will:
have an implied ?inline=*
no filtering
Resource's default properties are excluded at the Resource level. Including versionid.
xref targets are not inlined
Resource level attributes with exportrequired=true are shown, else not
The above semantics are ok however there are a few things are are less than ideal:
a static file server can't support ?export and therefore the user can't get a document view of the registry
switching from ?export to $export is an option but that's a LOT of work for someone to create all of the various ...$export files throughout the entire directory structure
"exportrequired" is a really hard concept to explain
Proposal:
keep ?export as is - allow it to be anywhere in the hierarchy, and keep it as an API server feature
add support for /export API that will be the same as GET /?export. This allows a static file server to still support "document view" but JUST at the root level, which is the most important usecase.
Today we have the
?export
flag that can appear at any level of the hierarchy to ask for a minimized view of the resource(s) being returned. In particular it will:?inline=*
versionid
.xref
targets are not inlinedexportrequired=true
are shown, else notThe above semantics are ok however there are a few things are are less than ideal:
?export
and therefore the user can't get a document view of the registry?export
to$export
is an option but that's a LOT of work for someone to create all of the various...$export
files throughout the entire directory structureProposal:
?export
as is - allow it to be anywhere in the hierarchy, and keep it as an API server feature/export
API that will be the same asGET /?export
. This allows a static file server to still support "document view" but JUST at the root level, which is the most important usecase.