It has the return type declared to be double.

That’s what the If-Match header is for. It prevents this problem.

That being said, I generally think PUTs are preferable to PATCHes for simplicity.

It’s about making APIs more flexible, permissive, and harder to misuse by clients. It’s a user-centric approach to API design. It’s not done to make it easier on backend. If anything, it can take extra effort by backend developers.

But you’d clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.

As I already said, it’s very simple with JSON Patch:

[
  { *op": "replace", "path": "/Name™, "value": "otherName"}
]

Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).

The semantics of the API contract is distinct from its implementation details (lazy loading).

Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn’t rely on that misfeature.

As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn’t have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.

Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.

Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you’ve created.

Only if using JSON merge patch, and that’s the only time it’s acceptable. But JSON patch should be preferred over JSON merge patch anyway.

Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.

Pretty dumb, honestly. If anything it just adds a Streisand effect to it as people try to figure out what’s censored.

Not that censoring it has any value whatsoever. Like if a child sees that, so fucking what?

Yeah it’s not all that uncommon in school, just increasingly uncommon in industry.

Glad you got fired. Vaccines should always be mandatory save for legitimate, doctor-validated medical exemptions.

Anti-vaxxers are fucking stupid and should either be educated properly or, if they still refuse to do their civic duty after being de-programmed of misinformation, punished. You are only allowed to participate in society if you take the necessary steps that you are morally and ethically obligated to do in order to protect it from preventable, transmissible disease. We had eradicated polio until stupid motherfuckers like yourself decided that it would be a good idea to forgo the standard polio vaccine schedule that we’ve had for decades. Now, we saw the first case in 30 years in 2022 because someone selfishly thought that their personal beliefs were more important than the health and livelihood of everyone else.

Yep. Postgres is fantastic and there’s no justification to use proprietary bullshit like that.

The issues are primarily with Azure, I believe.

From what I recall, particularly the younger generations that exclusively use mobile devices (though of course this is not limited to them) actually have terrible tech literacy across the board, primarily related to spending all of their time in apps that basically spoon-feed functionality in a closed ecosystem. In particular, these groups are particularly vulnerable to very basic scams and phishing attacks.

VMware workstation supports using a GPU. You can even use it in “pass-through” mode to give the VM full, exclusive access to the GPU.

Yeah that’s what I was referring to by “archaic”. Pretty much anything using the LAMP stack falls in that category. I don’t generally see new things using it.

Databases aren’t related to VMs or containers.

https://en.m.wikipedia.org/wiki/Database does a good job of describing what a database is. That page also has a lot of examples of uses of databases.

To answer your question about MySQL: in my experience it’s rarely used outside of classrooms or archaic systems. Postgres is a much better general-purpose option for SQL. Sqlite is also nice for different use cases (such as a database on a mobile device).

I used to work for a company that made software built on VMware. The biggest customer was using hundreds of thousands of VMs. Pretty sure they’re working on moving off VMware now because of all this bullshit.

But yeah, it’s gonna take a long time to move off.

No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.

Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.

Sure… That"s what libraries are for. No one hand-rolls that stuff. You can do all of that just fine (and, actually, in a lot less code, mostly because Java is so fucking verbose) without using the nightmare that is Spring.

I know it’s a joke, but just wanted to say that Uranium used for fuel is not something you can actually use for weaponry directly. It requires enrichment to increase the concentration of U-235 to weapons-grade levels.