Return NoContent for missing (optional) files

[ivarne]

RuleConfiguration.js and RuleHandler.js will soon be deprecated and removed from the app template. Frontend still needs to poll for the files for backwards compatibility, but showing permanent 404 in the browser console is a bad developer experience.

This suggest to change the return code to 204 no content, but it should not be released in backend before a released version of frontend is tested and verified to support this new behaviour. It seems to work fine as is.

Related Issue(s)

• Remove RuleHandler.js when expressions cover all features app-template-dotnet#169

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

[RonnyB71]

We had a discussion about this yesterday and feel that the 404 is the correct status for a file that is requested from frontend and should be there. Also the "will soon be deprecated" is something we need to discuss as we can't deprecated it until we have alternative solutions for custom code.

[ivarne]

Why should RuleConfiguration.json and RuleHandler.js be handled differently? 404 is tracked by application insights as an error, and an app that is missing RuleHandler is definitely not erronious.

[RonnyB71]

Valid point and probably they shouldn't be treated differently. The reason why the are is probably historical and of no value.

We did a quick re-run of yesterdays discussion and realized we didn't consider the optional aspects of these files. Only that a file was requested and it doesn't exists. So the api purists in us won:-D Some of the config files should definitely return 404 as it is an error if they don't exists. These two however, are optional might very well be left blank as well.

Approving now, and thx for continuously challenging:)

[RonnyB71]

🕹️

[ivarne]

I'm actually not against the purist opinion, if that would include giving frontend an alternative to just calling the API and look at the response when it wants to know if the old dynamics is used. Maybe a {org}/{app}/features endpoint that returns a set of feature flags.

[olemartinorg]

I've been looking into something of that sort when implementing this issue:

• Repeating groups: ProcessDataWrite mangler info om hva som har trigget eventet app-frontend-react#810

To be more specific, it requests {org}/{app}/api/v1/featureset, which currently fails with a 404 on existing apps. However, it is expected (for that task) that the endpoint is created at some point, and returns a list of features supported on that backend version. Currently, the only recognized feature there is 'multipart saving' which allows for a multipart request for each data model save operation that includes details about which parts have changed since last time (along with their previous values).

[ivarne]

Nice! You should probably add the PR to app-lib-dotnet for the endpoint to answer [] with 200 OK as soon as possible, so that logs don't fill up with 404 when the functionality actually launches in frontend. Then you can change it to ["multipart saving"] when you have a backend that supports it.