vfaronov
Perhaps one difference is that, while panics are always avoidable in a recovery function, stack overflows are not (if it happens to be deep enough already). Does the argument go “even a seemingly safe recovery function can’t be guaranteed to succeed, so prevent the illusion of safety”?
(To be clear: I’m not arguing, just trying to understand.)
Can you expand on this or link to any further reading? I just realized that this affects my platform (Go) as well, but I don't understand the reasoning. Why can't stack overflow be treated just like any other exception, unwinding the stack up to the nearest frame that has catch/recover in place (if any)?
If you want simplicity, and you fully control both sides, and you don’t care about the systemic advantages that REST purports to provide, then your best bet is to avoid HTTP altogether (which in practical terms may of course mean tunneling through it) and stick to a simple, modern RPC protocol.
> It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
> If you have multiple systems with data, and you want to merge the data together into a unified whole for some reason
This isn’t just about “big data” or “data warehousing” or such OLAPy concerns. It’s really about the bread and butter of modern information systems.
“Get some ID from service A, use it to query service B.” Does that sound familiar? That’s data integration for you. That’s what RDF / Linked Data is about.
It may be read as an argument against making namespaces a ubiquitous part of JSON, in the same way as they are ubiquitous in XML (even though not part of the base XML spec). It’s a valid argument against getting to the point where namespaces pop up in every JSON tutorial, and every JSON serializer takes a namespace map, and every user of JSON has to deal with them.
But JSON-LD (as RDF) uses namespaces to solve a particular problem (merging data from disparate sources). Solutions involve costs, that’s normal. You might weigh this cost against the expected payoff and decide it’s not worth it for you — but the article doesn’t do that.
> reliance on the web infrastructure (IRI, DNS, web servers, ...)
This is the whole point of RDF. It is what enables Linked Data.
> I read the history of JSON-LD by one of its main author [1], and it does not originated in the RDF community.
Not sure what you mean exactly, but here’s from http://manu.sporny.org/2014/json-ld-origins/:
> JSON-LD started around late 2008 as the work on RDFa 1.0 was wrapping up. We were under pressure [...] to come up with a good way of programming against RDFa data.
JSON-LD definitely was always an RDF serialization, created by people intimately familiar with RDF and the Semantic Web.
Are you thinking of “green”/M:N threading (as found e.g. in Go)?
Async/await (as found e.g. in Python) is precisely what hinders the style you describe: If your brand new I/O routine is “async colored” to take advantage of non-blocking syscalls, you can’t easily call it from your regular “sync colored” code without “spilling the color” all around, i.e. considerable refactoring.
What do people more knowledgeable in the field think about this?
Absolutely. This is a common practice and there’s even a proposed standard for it (RFC 7807). But such a payload need not be sent with 200 (OK). It can refine the status code instead of overriding it.
HTTP is not a closed protocol. There will never be a single document defining all HTTP methods, status codes and such. Nothing in the definition of status code 422 makes it inapplicable to non-WebDAV applications. It is as much standard HTTP as status code 400 is (both are “proposed standards” in IETF terms).
As explained by the same author: http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-...
Why is this a problem? Is the check heavy somehow? An hour between quick checks sounds like a reasonable interval for a security-sensitive app.
> You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.
This is sort of the fundamental limit of the format they chose.
On a related note, I’m quietly amazed why there isn’t yet a working generator of electronic music. I mean something that I can download, run, and it would stream believable IDM/techno/trance into my earphones. It sounds like it should be so possible, if not outright easy — yet it’s still humans who are toiling away at their Abletons weeding through that search space. I wonder what crucial problem I’m not seeing.
TLS is not inherently required for HTTP/2 on the backend.
TLS is sort of required on the frontend mainly because browser vendors don’t want to deal with broken middleware that expects all traffic on TCP port 80 to be HTTP/1.x.
This is less of a concern on the backend, and there are practical implementations of cleartext HTTP/2 today, including nginx and Apache on the server side, libcurl on the client side, and others.
“Your own web server” here means “your own program that serves HTTP requests”, and yes, people write programs like that all the time.
Can you cite a source for this?
In my practice, the servers behind nginx are usually platform-specific application servers, such as Gunicorn or uWSGI for Python.
Also, you would still need something else for HTTP/1.x. Even an HTTP/2 client does not have to support server push, and can even ask the server to disable it.
Why do you think server-sent events are not HTTP-y? I found them as elegant as modern Web technology gets.