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.
duglin
commented
25 minutes ago
Today we have the
?exportflag 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.xreftargets are not inlinedexportrequired=trueare shown, else notThe above semantics are ok however there are a few things are are less than ideal:
?exportand therefore the user can't get a document view of the registry?exportto$exportis an option but that's a LOT of work for someone to create all of the various...$exportfiles throughout the entire directory structureProposal:
?exportas is - allow it to be anywhere in the hierarchy, and keep it as an API server feature/exportAPI 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.