Helper is a code smell as it's a sign of "we don't know what the responsibility of this is or what to call it so we'll just chuck a load of shit in this file and call it a helper". The methods in should belong to something and live on that class, not in an external class.
RequestExtensions is more shit than the original solution. Extension methods are even worse! Shoot the reviewer.
For example would you argue against string formatting helpers? Or would they need to be written to an interface and added to myriad DI bucket lists?
String formats are data so they would be stored as constants so that they are interned. They can be stored in a const class which is a static class with no methods i.e.:
sealed class StringFormats {
public const DateFormatX = @"...";
}
The Haskell community has its dogmas too. And it's fair share of "let's do this simpler" blog posts.
As an aside Haskell has many equivalents of dependency injection and sugars to help and you can "inject all the things" there too.
My point is to think of the problem you are trying to solve, rather than ticking off the SOLID / Martin Fowler etc. tick boxes.
Understanding OO patterns, SOLID etc is a good thing but being prepared to "break the rules" is good IMO too.
Every exception I have shot myself.
Duly noted! Although I'll try talking to her first, I'm sure there's more behind the decision :)
One of the methods that was inside takes a request, extracts the body and returns the parsed graph from the body. It's used by many controllers from many projects. I don't know where to put such a thing, hence the request extension.
Usually that's a single responsibility class:
interface IGraphParser {
Graph Parse(Request request);
}