add _artifacts key to element json (should need to ignore it if found in regular element json post?)
2. add POST projects/projectid/refs/refid/elements/elementid for multipart/form-data content type
file = file to post
(can be expanded in future to include metadata of element itself, or allow multiple files with different mimetypes for same element)
mimetype can be derived from the file itself, or it can be part of form data as fallback if cannot be derived(?)
locationType is internal
successful post updates the element json stored to include or update the location for the mimetype, results in a commit, returns json of the element with the _artifacts array
3. Java interface
/project/projectid/refs/refid/elements/elementid with Accept header equal to one of the mimetypes (allow commitId query param) (if Accept not specified assume application/json for element json)
can also add /project/projectid/refs/refid/elements/elemnetid.xxx where xxx corresponds to extension of mimetypes (TBA?)
if requested artifact is external or not found throw error (how to add external artifacts is TBD)
about ignoring _artifacts key when doing regular posting - maybe it can be made generic by having a injectable set of strings that can be added to by modules, similar to how schema options can be populated, then the controller can just remove them from the input before passing it on
This story is done and ready for review.
I went with a pre-commit subscriber pattern to allow control over _artifact keys in a generic way. I’m not 100% sold on this method, since it only plugs into the DefaultNodeService, and would have to added to others if they don’t use DefaultNodeService. Maybe it would be good to add an abstract class level between the interface and DefaultNodeService to make this more ingrained?
To get the desired behavior from the get element endpoint I went with an Interceptor pattern. This requires the WebSecurityConfigurerAdapter of the application to add the interceptors, so maybe it would be good to add an SdvcWebSecurityConfigurerAdapter that does this by default.
for the interceptor, spring already has facilities for routing different content type requests (commented on pr), so it’ll be cleaner to use that
the pre-commit subscriber i agree should live someplace higher (pre commit is a misnomer? this is more like a post-input …i think of pre-commit as literally right before it gets saved to the store). An abstract layer sounds good
added a comment to the pr - what’s bothering me is the need to check for the artifact controller at the service level. I think having an abstract layer is still good for future cases, but in this case the hook should really be at the controller level