It’s ok, as long as you make sure to use mongodb it will be webscale no matter what. But if you date use anything else, it won’t be.

misdiagnosing errors originating from transport as application errors, and vice versa.

Shouldn’t the response body disambiguaite clearly whose fault it is? I mean you have to anyway if you advocate for ‘200 for everything’. You still have that same response body whether the HTTP status code is 200 or 500.

We honor the status code while providing an error body and it’s always blatantly obvious whether it’s an infrastructure issue or “true backend” issue when we see an issue. In my team I can’t recall anyone ever getting confused for even a little bit about whether an observed anomaly was web infrastructure or the backend, despite us setting HTTP status codes to error when, you know, we see an error.

I think the challenge is that it looks like a lot of other ‘standards’ I’ve seen: on one hand tediously specific yet on the other hand, so open ended as to largely defeat the point.

Every problem must have a ‘type’. Ok, fine, so what are the semantics of the ‘problem type’? Well, nothing in particular, just has to be defined, but it might be nice if it’s a url telling a human about your own human thoughts on the type. Also, if you encounter multiple ‘errors’, you need to omit any that you arbitrarily fail to group into the same ‘type’ which shouldn’t be subjectively too vague either, so don’t think about making catch-all types so you don’t have to discard some of the errors.

You can’t count on the members, and a problem type may arbitrarily ‘extend’ to completely rearrange those members into members of child objects instead, but that’s really all up to the backend to decide however they want to arrange it, with no prescribed standard for error bundling, but an example of how a backend could voluntarily implement such bundling as an implementer specific extension if they like, but again, don’t bundle errors that shouldn’t seem to be of a common type…

Also I think it’s funny that they say do this in the name of being a good web citizen, but then say send this new mime type down, client’s Accept header value be damned.

It purports to drive toward “machine-readable” problems but it seems like there’s not much actually actionable and the client has to in practical terms do a bunch of bespoke handling to deal with a backend that is still pretty much open to do whatever they like.

It has a couple of reasonable seeming examples, but nothing that would make me think “Oh, you implement RFC 9457? Then I already have error handling code ready to go!”

I’ve seen all sorts of complex errors generated by backends that have all sorts of features like this and more (error messages with parameterized string values, json pointers to specific problematic pieces of the client request. However people just want a human readable response to pass along. I could imagine the example ‘pointer’ being useful to map error details to a client maintained form, but that’s not even the ‘standard’, just a random example ‘extension’…

I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.

That’s certainly an unusual take. If you are a backend to HTTP and something throws a completely bogus URL out of left field at you, that’s not by any means a backend error.

I guess your take is that it might be some sort of usability issue or such because if 95% of clients try to hit the same non-existant URL, that probably means there’s some reasonable expectation that you should do something about the URL. However that’s relatively more rare a sort of ‘invalid URL’ scenario. The vast vast majority are some sort of scanners trying bogus crap, followed by an impossibly diverse set of typos and peculiar one-off assumptions that you can’t possibly reasonably cover.

I’d easily take that over ‘200 for everything’. If at least errors are distinct from success, I’d take that as a win. My standards have been lowered by so many ‘200 for everything’ backends…

My particular project did embrace HATEOAS, just other teams did not.

For people with Linux experience, I point to sys and proc as examples of some of the best principles of “REST” in play. You can get far exploring it and if nothing else it gives you some good discoverable clues for searching what you want.

Proxmox did something similarly nice by publishing a lot of their model via a fuse filesystem.

Imitating a filesystem like interface is a useful approach, and “REST” is the closest buzzy things to get people on that page.

But what is the value of a 200 OK when the request absolutely failed? As a caller, I don’t care that it successfully was conveyed but still utterly failed. Depending on my usage, I may only care about pass/ fail and the backend insisting I have to handle multiple different ways of expressing failure is just more work with no value.

Using 500 does nothing to preclude your application errors. If the caller wants nuance, it can still have it in the body or headers.

Fully agree, purity of REST is dubious, but a ‘REST-as-possible’ absolutely is helpful to keep people from going way of the rails in ways that annoy external consumers of their API. One API I dealt with claimed to be ‘REST’ but basically everything you did was ‘Create a Task’, ‘Get Task’. No modeling of state other than the state of remote function calls, which might have been nice for them but now I have to lean what tasks are possible and how to create them when a more REST like hierarchy would have been a bit closer to ‘self documenting’.

Yes, there are certain things that don’t map to key principles of REST, and I have upon occasion see people way too hooked on purity of REST for any practical end.

However, to the extent that you at least consider how it could map, then that’s helpful.

If you say “you can’t have an application error, you must ONLY use HTTP error codes”, that would be bogus. But if your application knows it has an error, why not also set HTTP status code to indicate an error as well? You have to set a status code anyway, might as well at least get the first digit right, or just 500 == error, 200 ==OK if you don’t want to hash out 4XX v. 5XX.

REST may not be sufficient, but that doesn’t mean it’s helpful to actively work against the HTTP semantics when they could be a vague indicator consistent with your API.

Think the point would be that it’s super easy to also set a ‘non-ok’ status in HTTP. Sure it may be insufficient for sophisticated handling, but at least you can get a vague sense of ‘something went wrong’…

Sure have your more specific API specific error code and your error details in the body, but at least toss a generic ‘500’ into the status code. I often find myself writing client software where I don’t need specific handling I just need to know ‘it failed’, and it’s obnoxious to deal with these interfaces where I have to sweat multiple potential ways for it to report failures when I just don’t care about the specifics. Sometimes an API doesn’t even have a consistent place that it sticks it’s return code, some don’t even define a reasonable way to know ‘failure’ and require you to explicitly map a huge number of ‘info’ to ascertain if it’s normal or error type state.

Fun fact, I actually did implement JSON-HAL and peers wondered why I was putting this “silly _links dictionary member” in there.

I’ll say I’ve seen other REST APIs using json and at least honor the concept of hypermedia, but in a useless way. They’ll have links specified, but even within their API no consistency on what dictionary keys would refer to related resources versus data.

I have had that argument repeatedly with people. People insisting that HTTP error codes are “transport layer” and it’s “wrong” for an API to hijack them to report “application level issues”.

No, the whole point of “REST” was to map application semantics to HTTP in a way that actually normalizes some things like error handling and expectations around whether an operation could be expected to be idempotent and make the namespace navigable.

At one point my work announced a person who was an external hire to be the ‘API genius’ to set my company straight. He came from a super reputable well known company so of course he just the smart guy to fix our technical mess. He had sent a message saying that he had reviewed the teams API and concluded they were not restful. I had a glimmer of optimism, that someone recognized as authoritative would call the RPC style HTTP usage that always returned 200 and steer toward sanity, or at least honesty. No, his feedback was that was all fine, but REST does not use JSON, REST uses Protobuf, so they need to change to Protobuf to claim to be REST. Of all the what the hell I could have predicted, that one was not in my book…

Left out being nagged to death about other products and services microsoft thinks you should buy.

Yes, but just like quality, the people in charge of money aren’t totally on top of security either. They just see superficially convincing tutorial fodder and start declaring they will soon be able to get rid of all those pesky people. Even if you convince them a human does it better, they are inclined to think ‘good enough for the price’.

So you can’t say “it’s no better than human at quality” and expect those people to be discouraged, it has to be pointed out how wildly off base it is.

One issue that remains is that the LLM doesn’t care if it is telling the truth or lying. To be a CEO, it needs to be more inclined to lie.

If, hypothetically, the code had the same efficacy and quality as human code, then it would be much cheaper and faster. Even if it was actually a little bit worse, it still would be amazingly useful.

My dishwasher sometimes doesn’t fully clean everything, it’s not as strong as a guarantee as doing it myself. I still use it because despite the lower quality wash that requires some spot washing, I still come out ahead.

Now this was hypothetical, LLM generated code is damn near useless for my usage, despite assumptions it would do a bit more. But if it did generate code that matched the request with comparable risk of bugs compared to doing it myself, I’d absolutely be using it. I suppose with the caveat that I have to consider the code within my ability to actual diagnose problems too…

Based on my experience, I’m skeptical someone that seemingly delegates their reasoning to an LLM were really good engineers in the first place.

Whenever I’ve tried, it’s been so useless that I can’t really develop a reflex, since it would have to actually help for me to get used to just letting it do it’s thing.

Meanwhile the people who are very bullish who are ostensibly the good engineers that I’ve worked with are the people who became pet engineers of executives and basically have long succeeded by sounding smart to those executives rather than doing anything or even providing concrete technical leadership. They are more like having something akin to Gartner on staff, except without even the data that at least Gartner actually gathers, even as Gartner is a useless entity with respect to actual guidance.

Feel like I’m being gaslit, the more I try to use them the less confident I become in their utility.

I will confess it did help me cut through some particularly obtuse documentation to provide a rough example of what I wanted to do. It still totally screwed up the actual suggestion, but it at least helped me figure out some good keywords to dig into.

It occasionally saves me some tedium when I have to do something mindlessly tedious, but doing that usually also inflicts constant misguesses about what next.

But even when doing easy stuff they are falling over constantly, and that hasn’t been significantly improving.

Interesting, but is that figure among those that actually register with the built in smart tv, or average for all purchases? The attach rate i would think for the smart features would be challenged by google and apple and roku pushing streaming sticks. The streaming sticks can probably just assume 100% attach but still seem to price with a little positive margin.