NIFI-15196 - Improve Content Viewer resolution based on MIME Type

[pvillard31]

Summary

NIFI-15196 - Improve Content Viewer resolution based on MIME Type

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for proposing this improvement @pvillard31.

On initial review, I'm concerned about introducing a new REST API method for this purpose, as it raises other questions about how Content Viewers are registered. It may be better to consider an approach that allows a Content Viewer to register for a MIME Type pattern, versus a specific type.

The Spring Web framework also has a powerful Media Type class that supports some of the matching against vendor extended types, which may be worth considering for implementation.

I plan to take a closer look in the near future,

[pvillard31]

I explored different approaches and it felt like the best approach with minimal changes while having all of this logic in a central place and reduce specific logic on the frontend side. I didn't look into built-in Spring capabilities, I can have a look at what could be the option there. But I think some API changes are required in any case, either with this new one or by changing the existing one but not sure that is desirable.

[exceptionfactory]

Thanks for the reply. My main initial concern is the new REST API method, as it adds another round trip for something that can be selected, although the resolution could be helpful in some scenarios.

[pvillard31]

Yeah, I do see a potential approach when content viewers are registered instead and have a pattern there. Let me give this a try.

[pvillard31]

Well, I don't see any good option in the end to have all of the logic on the backend side. The simplest approach would be to add the patterns directly into the file https://github.com/apache/nifi/blob/main/nifi-extension-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/webapp/META-INF/nifi-content-viewer and then do the pattern matching on the frontend side. I guess that could be OK but we are back at the discussion in the comments on the issue.

[pvillard31]

I pushed a commit to switch to the very simple approach as a way to discuss both approaches.

[exceptionfactory]

Thanks for the alternative approach @pvillard31.

I will take a closer look at options, but it does seem like something along the simplified compatible check is a better option.

At a high level, a MIME Type such as application/vnd.something+json is fundamentally application/json, and that holds true of substituting anything for vnd.something with the + character. From that perspective, if a Content Viewer indicates support for application/json, it automatically supports any extension and should not necessarily need to include a pattern for matching. As you have in the simplified approach, this does put more responsibility on the frontend viewer to implement the compatibility checking, but that seems reasonable given the direct equivalence of extended types.

I would look for more input from others on the frontend side before getting too far, but this does help move the discussion forward to something tangible.

[exceptionfactory]

Returning to this pull request after some time, what do you think about reverting the changes to the nifi-content-viewer types, but keeping the general approach of the isMediaTypeCompatible() method? Specifically, instead of having the Content Viewer register a supported Media Type pattern, the content viewer should attempt to find a compatible viewer.

In terms of logic, with the media type matches, it continues to work as it does today. If it does not match, it would attempt to resolve the "base media type" as type/subtype using a regular expression to match the type and the subtype that follows the literal + character. This strategy should be viable based on the fact that specific types like application/vnd.api+json are constrained types of the more general application/json type. If the resolved base media type matches one of the registered types, then that content viewer could be selected.

[pvillard31]

I followed your suggestion and forced pushed a single commit to rebase on top of latest main

[mcgilman]

Thanks for the PR @pvillard31! The changes look good but could we please include some additional test coverage for the new logic?

[pvillard31]

Done, thanks @mcgilman

[mcgilman]

Thanks @pvillard31! Will merge once CI completes.