@JensG I think it's a fad and lack of reflection in part as you point out. But also people sometimes want JSON over HTTP (which is OK to use) and then erroneously jump to REST. Maybe that's another mental failure mode. I am continuously amazed by the amount of group think present in the developer community. Developers are supposed to be these emotionless, rational people and then this stuff happens over and over! Total #fail causing enormous damages to the company.

You need to ask: What are you gaining from REST at all? I believe many projects gain exactly zero from using a REST style API. REST is a rather incredible fad where in some instances otherwise smart people do not realize they gain nothing from it but pain.

.NET has a tendency to prepend a BOM. I think they made it that way at the time because it was important to differentiate UTF8 from other common encodings. Might have been a mistake.

I often write tests using the real database and no mock objects at all. Works really well in many cases. And then you don't need interfaces most of the time. If you have a UserService that class is just a holder for logic. It gets injected a database connection and tests run inside of a transaction that is rolled back. Many would call this bad practice but I found that this works extremely well. Don't need to contort your code just for testing and you get the bug finding power of integration tests.

Do not be deterred by blanket rules such as avoiding partials. If it works for you it's good.

Can you programmatically create a fresh repository for each test run?

@RobertHarvey I see no issue in making them do this. Further, my answer proposes combining queues and databases. Use the queue for queuing work and the database for storing data.

If you want a good answer you probably need to explain the architecture in more detail, possibly using an image.

Consider OOP as just another pattern that you can apply at the right time. OOP not a framework that can methodically solve every task. Such a thing does not exist in software engineering.

This is actually the most practical answer. The testing answers do not provide a way to simply write a correct loop on the first try. I tend to plug in values to the loop iteration variables, not so much to the boundary expressions.

At my company, we use a separate SVN repository for every component of the system. I feel for you. Every company I consulted with did this. Architecture astronauts at work.

Throwing is not automatically an LSP violation. It would be totally valid to have a method Assert(bool) that is contractually required to throw iff the argument is false. Throwing really is just like a special return value. Any behavior at all can be part of a contract including formatting your disk.; The scenario you describe is a bug in the client (you seem to agree with that). Not in the class.

Whether you leave reload() blank or whether standardActions does not contain a reload action is just a different mechanism. There's no fundamental difference. You can do both. => Your solution is viable (which was your question).; Sword does not need to know about reload if Weapon contains a blank default implementation.

You can do class Weapon { bool supportsReload(); void reload(); }. Clients would test if supported before reloading. reload is defined contractually to throw iff !supportsReload(). That adheres to the LSP iff drived classes adhere to the protocol I just outlined.

It's a testament to how messed up HttpClient is that using it is a "weekend read" as commented by @AnkitVijay.

This is accurate in C# as well. The base class library follows this convention.