In other words, in the context of REST APIs, the result of making a request shouldn’t change the state of the application more than once. That is, you make the same request multiple times, there should be no side effects such that the same result is sent each time.
Or, perhaps even more simply, if the same request is sent more than once, it’ll only be processed once.
Secondly, the crux of the article has a great breakdown of the various methods that should exist in a REST API:
GET Method: The GET method is used to retrieve a resource from the server. It is an idempotent method because retrieving the same resource multiple times will not change the resource itself or cause any side effects on the server.
PUT Method: The PUT method is used to update a resource on the server. It is idempotent because sending the same request multiple times will result in the same resource state as if the request had only been sent once. For example, if you send a PUT request to update a user’s email address with the same new email address multiple times, the user’s email address will only be updated once.
DELETE Method: The DELETE method is used to delete a resource from the server. It is idempotent because deleting a resource multiple times will have the same result as deleting it only once. If the resource has already been deleted, sending a DELETE request for the same resource will not result in any changes.
POST Method: The POST method is used to create a new resource on the server or to submit data to be processed. It is not idempotent because sending the same request multiple times will create multiple resources or submit the same data multiple times, resulting in different outcomes.
And keeping this in mind is very helpful when designing an API.
Ultimately, I share this because the article does a great job of breaking down the concepts of idempotency in REST API design and the supporting application. And it’s a good reminder to have on hand whenever I’m – or you, whoever you are ::s
At the time of this post, I see the following whenever which I run $ which php:
And when I run $ php -v, I’ll see the following output:
PHP 7.4.33 (cli) (built: Jul 13 2023 17:41:11) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Xdebug v3.1.2, Copyright (c) 2002-2021, by Derick Rethans
with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies
But if I was to run phpinfo(); within a page hosted via Laravel, I’d get PHP8. This is problematic because if I’m working on a function that I’m eventually going to incorporate in an app that runs in the browser, there may be functionality that doesn’t work as I expect.
As such, it’s important to make sure we have parity between Laravel and our system’s binary. To do this, issue the following command in the terminal:
$ valet use email@example.com
$ valet restart
Obviously, you’ll change the value of firstname.lastname@example.org to whatever you want to use on your machine. Whatever it is, though, make sure there’s parity between the two. This way, whenever you run a script independently, then you’ll have the same results in the browser as you do in your terminal.
Years ago, I started writing small utility plugins that helped me maintain any given task on managing this site or projects that I was building for others.
Some of these plugins I’ve kept just for me because they are quickly put together and built in such a way that are geared towards this site; others I’ve open-sourced, shared, and/or installed on other sites because a person with whom I was working was interested in the functionality or because it was niche enough that it solved a single problem they didn’t want to deal with.
Many of these have been archived because I didn’t need them, didn’t want to maintain them, or no longer had a use for them. Case in point: Page Template Dashboard.
But these types of plugins, at least for me, date back over a decade. The first plugin I ever released in the WordPress Plugin Repository was called Tipsy Social Icons. This year, it will be 11 years old (not that I maintain it anymore but get a look at the plugin page to get some good social web nostalgia).
It was written one afternoon when there was a rare snow storm in Georgia and we couldn’t go anywhere. 🙃
Anyway, there’s something to be said for large plugins that greatly extend WordPress in all kinds of ways such that we practically have full applications running within WordPress that help users do things far beyond posts, pages, taxonomies, and user management. Be it something that runs in the browser, something that serves as a headless application, or something else. There’s a reason WordPress can be referred to as the operating system for the web.
But there’s also something to be said for small tools or utilities that do something either that require user interaction or that take care of something behind the scenes. I see the occasional discussion about this [whenever I am lurking] on Twitter, in newsletters, or in other Slack channels [in which I am lurking].
That is, people seem to be interested in them, people want to build them (or they want them built), but they seem fewer and far between given the size of other plugins that are available.
So it raises a question: Where are they? Is there a market for utility plugins? Are they overshadowed by larger projects? Is it too hard to find them given the way GitHub or the WordPress Plugin Repository is structured?
These aren’t loaded questions; instead, they’re general musings on the whole thing.
For those of you reading this who have been in WordPress for a long time, you’ll remember some of this and for those of you who may be newer consider it a cautionary tale:
Years ago, we had what was essentially a race to the bottom for product pricing. The idea was something like “s/he who sells the most at the lowest price wins.” This could be for plugins but it started with themes.
Then we moved in the subscription model which we see every where both inside WordPress and outside of WordPress.
It’s not that I need an lesson on economics to understand this dynamic but there’s also alternatives especially in projects that aren’t the backbone of a person’s livelihood or their business.
People talk a lot about “side hustles” and each person has their own motivations for having them. (That is, some want to turn them into full businesses, some just want a hobby.)
This is where I think this idea of utility plugins come into the picture again (granted, I don’t think this is an elegant term to describe a product but that’s beside the point – for now).
Instead, I think there’s a small model by which extremely simple plugins can be marketed for a specific problem and sold at a price that doesn’t require a subscription, that doesn’t drain a person’s wallet, and that helps them when using WordPress by simply doing a job that keeps them from having to do it.
Further, “extremely simple” may be an overloaded phrase. Some of the simplest solutions are not in how few lines of code or how much is going on behind the scenes but how simple it comes across to the user.
Does it require activation, user input, settings values, and so on
Does it just require activation?
Alternatively, simple plugins can be just that. It might be an anonymous function that’s associated with a hook that adds or removes a single UI element.
Despite talking semantics here, that’s not what I’m after. Instead, I’m talking about a market for utility plugins where a utility plugin is defined as a single plugin that’s activated and does one thing with minimal user input and that enhances or streamlines their work within WordPress.
It does a job they don’t want to do (maybe once, maybe multiple times, maybe always), stays out of their way, and allows them to focus on what they need or what they want to do.
Personally, I think there’s a market for them. I don’t know how large or how small it is nor do I think there’s a consistent price point at which they can be placed (how do you value someone’s time when it’s a single WordPress installation that’s a hobby or someone who maintains an entire set of WordPress installations?).
There are ways to test this, though. And I’ve a list of ~25 plugins that I’d love to actually try to implement.
Since there are a few extensions I’ve wanted to try out that aren’t available for Visual Studio Code’s stable builds, I’ve been using Visual Studio Code Insiders for the last few weeks.
The main difference is that this version is a daily release versus the standard monthly release and certain plugins, like GitHub Copilot Chat, requires the daily builds for it to run.
Here’s the thing, though: If you have settings you want to preserve across installations and Settings Sync doesn’t do the trick (I had hit or miss success with it across the two editions of the IDE), then here’s a simple trick for symbolically linking extensions, settings, and keybindings across editions.
There are better parameters to evaluate quality, not quantity, of the time spent staring at your screens:
Does this app do its job and then politely step aside?
Does it linger in your brain like an awkward party guest at 2:30 A.M. after everyone else already left?
Did I summon this app, or did it summon me via notifications?
One of the best things I’ve done since my “digital detox” (see here and here) at the beginning of last year was to turn off only notifications that weren’t urgent. Of course, what’s considered urgent for me isn’t going to be what’s urgent for you.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.