The power of URLs you can use with query parameters and a HTTP GET request

December 22, 2022

I recently wrote about some aspects of my dmenu setup, including using a custom $PATH that contains a bunch of little utility scripts. These little scripts are an important part of making my dmenu setup so useful and a crucial building block of my environment, but in turn a lot of them are enabled by something else. In practice, a lot of what I do with dmenu is to open a Firefox window on some sort of URL, and in turn this is relies on being able to create URLs that do useful things, like perform a web search.

Some of those URLs can be readily formed because they have a predictable structure, such as packages in the Python standard library or packages in the Go standard library. If you know the name of a standard package in either language, it's easy to create the URL for it, which in turn makes it easy to write a little script that will open a new Firefox window showing a particular package's documentation (especially if you don't bother with error checking if the package actually exists).

However, not all things in the world can reasonable be addressed with plain URLs, for various reasons. For other things, it's both useful and powerful to be able to address them using URLs that have query parameters attached. URLs with query parameters aren't the only way to pass such extra information around (for example, you could use HTML forms and pass them as form parameters in a POST), but they have the great virtue that it's easy to open browser windows on the results, since from the browser's perspective they're just another URL to make a GET request on.

(Many other tools also have a much easier time with GET requests than with other forms of requests.)

What this says to me is that if you're setting up a local web application, if at all possible you should make it accessible either through URL patterns (in the simple case) or through URLs with query parameters (in the more complex pattern of search). This is the traditional web application implementation of searching or looking things up, but it's not necessarily universal and sometimes it can feel like more work (your framework might encourage use of POST with forms, for example, and make GET based usage more difficult; the Django framework is a bit like this).

(There are even public websites that are exceptions and want you to use POST, although sometimes you can make GET queries with query parameters anyway.)

This is in a sense obvious, but it's the first time I've put it all together in my head and realized how important support for GET query parameters are for my collection of little dmenu scripts (both for web searches and to do things like search some of our local documentation).


Comments on this page:

By Michael at 2022-12-23 03:28:51:

It's definitely not optimal, but in a pinch, if you (for some value of "you") actually need to access something on the web by programmatically pointing a browser instance at it and accessing this thing actually requires making a POST request, you can make a small HTML drop file that contains an auto-submitted (using Javascript) form to make the POST request itself.

But yes, GET requests with query parameters is certainly far easier.

And maybe it's just me, but I feel that POST requests (with their opaque parameter structure) are potentially less stable than GET requests (with query parameters that you can actually see directly). There is more of an implied contract with the end user that the URL keeps working when the end user can do something like copy the URL elsewhere and it works immediately to bring up the same content.

Written on 22 December 2022.
« The Prometheus cardinality issues with systemd unit-related metrics
Handling numbers in Vim when they have a dash in front of them »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Dec 22 22:44:03 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.