The problem with history is that you need to know when to look. If you're looking for some old code that you know existed but you don't know exactly what it was, you can't just browse to go and find it.
You can return whatever HTTP response code you want, but if you care about knowing whether your site is working being about to look at the logs and see "That user requested a page that doesn't exist" being different to "That user requested a page that exists but had no results" is quite useful. In coding terms it's the difference between a null and an empty array.
You can do that with filtering, which should be a feature of every single logging tools.
Anyway, I agree that when you filter via queries, an empty list is more valid response than 404. That HTTP status should be returned IMHO when the requested (for example by id) item is not found (and of course with wrong paths, etc).
In this case I don't think the status should depend on the number of results. Here are you results, [] is a valid response body when there are no result. Returning 404 if there are no result (GET /books?title=a for instance) is misleading, the caller may think that /books is a non existent route and may conclude that books are reachable via another URI. To me, the querystring has no influence on the response status.
/books/1 could return 200 or 404 depending on the existence of the book#1, here it make sense because if /books/1 does not exist the API must tell it explicitly. However 404 belongs to the 4XX family which means "client error", is it an error to ask for a non existing book ? If you enter in a bookshop and ask for a book they don't have you did not "make a mistake". It's not like if you asked for a chainsaw. But in an API, especially with hypermedia, you are not supposed to request a resource that does not exist (unless the API provides a link to an existing resource that is was deleted before the caller try to reach it).
If you enter a bookshop and you ask for a book that does not exist then it's definitely your mistake.
If you ask for a book they don't have it's a different matter.
In any case, when you ask for a book in a library you are using their "search" endpoint. The equivalent to opening a books/1 url would be asking for a specific instance of a book by serial number or so. Then it's clear that you made a mistake uf you do that for an unexistent serial number...
A response code of 204 seems more appropriate but the problem is you're not allowed to send further information, which would make that descriptive response... not descriptive enough.
Yes, and this is obvious if /users/ exists and returns a 400 if the ID is required. That way you can tell the difference between /users/ being there and expecting and ID, and it not being there.
Of course it is technically possible, but doing so would violate the spec.
> The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
In the above case, the server _is_ returning a representation.
Another reason not to return a 404 in that case is that chances there will be monitor tooling in place that will treat a 404 as an "error" that will show up in your alerting, but would not be ideal; it will just be noise.
I can't globally disable that "autofill" also hits "submit". I want to review what it autofills before I submit. I consider this a security risk. I can disable submit only on a login-by-login basis, and my coworkers are able to reenable it again. I can't globally disable it for myself.
This setting does exist for "Universal Autofill" [1] which is what I use instead of any browser extensions because I don't want to get phished when I'm not at my best. [2] [3]
On the Mac app, the setting is at the bottom of the General settings screen.
The downside to forgoing the browser extensions is that creating new logins is painfully manual. The risks of using the extensions just freak me out too much.
Painfully manual. Every time I have to delete the word "Login" when creating new login, I wonder how hard could it be to vibecode myself what I want. I fantasize about getting a job there to fix the UX issues and then quit.
I have been telling people for years that biometrics (face, fingerprint, voice) is your username, not your password. But people are easily swayed by convenience.
For all intents an purposes it is, especially face ID. Also, courts in most countries can compel you to provide biometrics. But many cannot compel you to reveal passwords.
Same. Sometimes I will play a givewayway game on EGS and like it enough to e.g. buy the DLC. In that case I'll buy the game on Steam, just to buy the DLC there too.
> It's like buy a $2000 TV and discovering ads on the homescreen, ContentID to sell your viewing habits, etc.
Have you bought a TV recently? This is exactly what is happening already. I had to pi-hole my entire network to get rid of the ads in my "switch source" menu on my Samsung TV that did not have ads when I bought it and for the first 3 years after that.
I only hooked up my Samsung TV to the internet to install one update when I first acquired it, then kept it disconnected. Thanks for the tip--I'll make sure to keep it offline forever now!
Me too. Switching my home system from Ubuntu back to Debian was influenced a lot by snap. I don't get how they could fumble that one so hard. It goes against everything they used to stand for. If I want a bloated, slow, closed-source, proprietary app store with unclear security ramifications, I'll install MacOS or Windows. It also feels like app developers at least care a little bit about those stores. Mozilla for example still officially recommends installing their Debian package rather than through snap on Linux, despite shipping via snap by default on Ubuntu now.
The dashboard itself is a react app talking to my Home Assitant instance over a websocket. The heavy lifting of bringing various data sources together is done by HA, I just wrote a react app because it seemed easier than learning to customize HA dashboards to the degree I wanted to.
The difference is that with financing you're stuck with it (and your credit rating drops, at least in the EU here). You're not stuck with a subscription. If your income changes and you can't afford it anymore then you can cancel your subscription.
In the US if you don't have any debt, that is bad for your credit rating. Perversely, the more debt you have, the easier it is to get more credit, at least up to a point.
Oh sure, my original comment’s point was just to allude to the point that costs are going up for all methods of compute, so that fact alone shouldn’t influence your buy versus rent versus finance decision too much.
This idea that there’s a conspiracy to take personal computing away from the masses seems far fetched to me.
reply