Browsers only allow users to make GET requests
Published on January 18, 2024 semantic-web rant programming protocol🚧 MESSY WRITING AHEAD 🚧
Foreword: I began writing this article out of frustration in
2023 and only finished it in 2024. The writing is very messy and
the article is a list of related thoughts and not a decisive battle
plan to fix the shortcomings of the internet.
Modern browsers effectively only allow users to perform GET requests, thus forcing users to interact with forms from within documents. This single design decision shaped the way the web works and turned it into the mess that it is today. Now let me explain.
The HTTP standard defines 8 request methods: GET, POST, PUT, PATCH, DELETE, HEAD, CONNECT, OPTIONS and TRACE.
In reality, developers mostly use the GET and POST request
methods, and users only directly use the GET request method (POST
requests are fired from within documents retrieved by the user via
GET requests).
In normal English: Users only go to pages via the
search bar or by clicking links; communication with the dynamic
part of a web service is done from within the page.
In even more normal English: To search on google
you have to access google.com,
load a document and then interact with the actual search service
through that document.
And even when HTML forms are used to send an POST request, the result is a page that flashes a popup when refreshed. I understand that, for technical reasons, this popup is needed and its usage completely reasonable. But I also feel like it adds extra friction to the browsing process, in some cases scaring away non-technical users.
The ability to only perform POST requests from inside of HTML documents also accelerated the need for more interactive documents. So we got Javascript.
The actual problem: Data becomes inseparable from UI
The actual problem is not that I can’t send POST requests from the search bar; it’s the fact that, in order to access the data we need from services like google, twitter, other social media and news sites, we must use the gateway they provide, with no possibility to reuse the data we requested.
This is the reason that we have vendor lock-ins, sluggish sites and the inability to choose how to consume content on the internet (you either hand over your free time to “The Algorithm™” or use RSS).
Modest proposal: Sematic XML + XSLT
XSLT is a stylesheet language for XML that lets you convert an XML document into an HTML document that has all the benefits of client-side Javascript-powered interactivity, while providing a way to decouple the data from the interface.
Modest proposal 2: Bookmarklet-like modals that can send post requests.
Here I present to you a modest proposal: In the same way we have bookmarklets to execute Javascript on the current page, we should add the ability to add bookmarks that open a simple popup that contains a traditional HTML form.
A checkbox in the corner that allows the user to open a new tab with the server response, and that’s everything we need to replace search bars on all websites.
New post on twitter? Just click this button in your toolbar,
write something in a textarea, upload screenshots of some drama
filled conversation using the holy <input type="file"
multiple />
and even pick a background color for your
avatar using <input type="color" />
.
And after posting your tweet, you would head over to twitter.com and be served an XML document as a
feed of <tweet></tweet>
s, which would be
styled with XSLT,
thus solving the problem of template duplication between the
client- and server-side.
Styled by XSLT, your tweet would have two buttons next to the content, one for deletion and one for editing. The delete button would send a simple DELETE request to the server, to which the browser could ask you if you’re sure. The edit button would use the same popup used to create the tweet, but send an PATCH request to the server.
Apologetics for the semantic web
Everyone saw it coming. The rant about the semantic web has arrived and it’s here with some good arguments in its favor.
With everything being done through GET requests and then dynamically displayed with javascript in the document, everything on the web feels very ad-hoc. The web doesn’t resemble a giant document retrieval system anymore, it has become a giant repository of interfaces that allow you to do things without having to download apps.
I won’t explain what the semantic web is, but I’ll present a possible workflow if it were a thing:
I open twitter.com and I’m served an XML document. I’ve configured my browser to use a different XSLT stylesheet for twitter.com to have a minimal UI with all the features that I need.
A tweet announcing an event uses microformatting to provide data to my browser about the event (location, date, contact information). My browser places some buttons allowing me to add this event to my calendar or to share it via email.
I look at the profile of the tweet author, and my browser, using the data provided by the microformats, places some buttons next to the profile of the author, allowing me to add him to my contacts with all the correct information about him (profile picture, email, phone number, website, description).
Microformats
To truly understand the power of microformats and their potential usage by browsers, look at microformats2.
A few microformats and their potential uses:
- addresses (
h-adr
): would allow browsers to give directions to the location from within the webpage. No need for copy-pasting into google maps. - contact information (
h-card
) with all its tags:p-name
,p-family-name
,p-nickname
,u-email
,u-logo
,u-photo
,p-adr
,p-post-office-box
,p-street-address
,p-geo
, etc. - events (
h-event
) - products (
h-product
): name, photo, brand, description, review, price - recipes (
h-recipe
): name, ingredients, instructions, duration, photos