Misunderstanding REST only to reinvent it in a more complex way. If your API speaks JSON, it's not REST unless/until you jump through all of these hoops to build a hypermedia client on top of it to translate the bespoke JSON into something meaningful.
Everyone ignores the "hypermedia constraint" part of REST and then has to work crazy magic to make up for it.
Instead, have your backend respond with HTML and you get everything else out of the box for free with a real REST interface.
This section is for you: https://overreacted.io/jsx-over-the-wire/#html-ssi-and-cgi
>Everyone ignores the "hypermedia constraint" part of REST and then has to work crazy magic to make up for it.
Right, that's why I've linked to https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... the moment we started talking about this. The post also clarifies multiple times that I'm talking about how REST is used in practice, not its "textbook" interpretation that nobody refers to except in these arguments.
Strawmanning the alternative as CGI with shell scripts really makes the entire post that much weaker.
> nobody refers to except in these arguments.
Be the change, maybe? People use REST like this because people write articles like this which uses REST this way.
I wasn't trying to strawman it--I was genuinely trying to show the historical progression. The snark was intended for the likely HN commenter who'd say this without reading, but the rest of the exploration is sincere. I tried to do it justice but lmk if I missed the mark.
>Be the change, maybe?
That's what I'm trying to do :-) This article is an argument for hypermedia as the API. See the shape of response here: https://overreacted.io/jsx-over-the-wire/#the-data-always-fl...
I think I've sufficiently motivated why that response isn't HTML originally; however, it can be turned into HTML which is also mentioned in the article.
And if it turns out that there is no such thing, should I conclude that all these people talking about it really just base their opinion on some academic talking points and are actually full of shit?
speak like someone who's never made a real product. Please enlighten us on how you add interactivity to your client, which flavour of spaghetti js? How do you handle client states, conveniently everything's on the backend?
And while we're at it, I'd like to know, why are people still building new and different game engines, programming languages, web browsers, operating systems, shells, etc, etc. Don't they know those things already exist?
/s
Joking aside, what's wrong with finding a new way of doing something? This is how we learn and discover things.
Whee!
#!/usr/bin/perl
$ENV{'REQUEST_METHOD'} =~ tr/a-z/A-Z/;
if ($ENV{'REQUEST_METHOD'} eq "GET") {
$buffer = $ENV{'QUERY_STRING'};
}
print "Content-type: text/html\n\n";
$post_id = $buffer;
$post_id =~ s/&.*//; # Get first parameter (before any &)
$post_id =~ s/[^a-zA-Z0-9\._-]//g; # Sanitize input
$truncate = ($buffer =~ /truncateContent=true/) ? 1 : 0;
$title = `mysql -u admin -p'password' -D blog --skip-column-names -e "SELECT title FROM posts WHERE url='$post_id'"`;
chomp($title);
$content = `mysql -u admin -p'password' -D blog --skip-column-names -e "SELECT content FROM posts WHERE url='$post_id'"`;
chomp($content);
if ($truncate) {
# Extract first paragraph (everything before the first blank line)
$first_paragraph = $content;
$first_paragraph =~ s/\n\n.*//s;
print "<h3><a href=\"/$post_id.html\">$title</a></h3>\n";
print "<p>$first_paragraph [...]</p>\n";
} else {
print "<h1>$title</h1>\n";
print "<p>\n";
print "$content\n";
print "</p>\n";
}
One bit of hopefully constructive feedback: your previous post ran about 60 printed pages, this one's closer to 40 (just using that as a rough proxy for time-to-read). I’ve only skimmed both for now, but I found it hard to pin down the main purpose or takeaway. An abstract-style opening and a clear conclusion would go a long way, like in academic papers. I think that makes dense material way more digestible.
- https://overreacted.io/jsx-over-the-wire/#recap-json-as-comp...
- https://overreacted.io/jsx-over-the-wire/#recap-components-a...
- https://overreacted.io/jsx-over-the-wire/#recap-jsx-over-the...
I don't think I can compress it further. Generally speaking I'm counting on other people carrying useful things out of my posts and finding more concise formats for those.
An outline doesn't have to be a compressed version, I think more like a map of the content, which tells me what to expect as I make progress through the article. You might consider using a structure like SCQA [1] or similar.
--
1: https://analytic-storytelling.com/scqa-what-is-it-how-does-i...