Inventory Classification Browse - add PUT method options override

Closing because default Acept header values will be extended in https://folio-org.atlassian.net/browse/STCON-154

Thanks for creating a PR to add application/json to defaults @Zak Burke . I think it’s a better option that having to override defaults every time

I see your point about not having actual stories bloat your backlog. As long as there’s a feature for it then it’s ok I think

@Denys Bohdan, to your “if STCON is deprecated where are the ‘refactor everything' tickets?” question: we’ve been recommending that people write new code with RQ for years now, and that’s largely what I mean by “it’s deprecated”.

Our PO likes to avoid tickets that don’t have a specific timeline because they bloat the backlog with stuff that never seems to get picked up. We don’t have actual tickets, but this work is a feature on our long-term roadmap, though not at the top.

@Denys Bohdan , CCing from the longer conversation on Slack:

My point is, this was a Chesterton’s fence thing. I’m being asked to get rid of a rule we’ve been living with happily for a loooong time, so I wanna know: do you understand why that rule was there? The argument at the beginning of this conversation (from the PR) is merely “This rule is in my way so I want to take it down” and that made me skeptical of the request.

What I’m learning here is that rule may be left over from insufficiently imaginative code (nah, we’ll never have errors, and they’ll never be json) that was insufficiently strict (nah, we don’t bother with content-type negotiation) and now that we have tools that do both those things, we need the UI to support this. This is a good reason to take down this rule.

Among other things, we learned Spring-based modules do content-type negotiation whereas old RMB-based modules likely don’t, so it’s less of a case that “we never had this problem before” than “we never noticed this problem before.”

Now for the next question: What is the best option?

1. add support for overriding the hard-coded Accept header content-types, as in the existing PR?

2. #1 and add application/json to the default, because these are JSON APIs and so we’d expect JSON errors. Good defaults in one place are way better than providing empty options that every single client is going to fill out in exactly the same way.

Hey @Zak Burke, I find it odd that stripes-connect is deprecated while we still have many components in stripes-smart-components that use it to fetch data. Do we have tickets in backlog to refactor those components to use react-query or something else?

This is not the first time we had this issue with headers as well - when deleting Authority Source files. If it’s a common issue then it’s probably worth adding this convention to development documentation