‘Its fine as long as people don’t use it’

Spring (a microservice library) deprecated matching on trailing slashes.

e.g. A request to /hello/world doesn’t match the endpoint /hello/world/

I found out when a client in another project was 404ing on the targeted endpoint post upgrade. I was at the end of an upgrade to this version after debugging the Spring requests matchers. 1 missing character took 5 hours to find. It was annoying.

The title is disingenuous. It’s not a direct quote from the post. However, I do believe it’s a fair summary of the comment that has stuck in my mind since July 2024.

I can see manually typing a URL as a real argument only in case of web apps (not APIs) and even there it’s only potentially useful for a few select URLs that are considered to be entry points into the application and are likely to be directly entered by the users.

– A Spring Contributor

I don’t mean this as a take-down of the contributor, or anyone involved with this change in general. They have the unenviable task of considering countless developers, their experience using their product, security, technical debt, etc. while trying to manage a framework and the community that formed around it. And sometimes, someone only joins the community to take a seat in the peanut gallery.

I can’t speak to the overarching security reasons for the change. I barely fell secure enough to make a post about interacting with computers. I really only want to talk about what I’ve been able to learn from thinking about it for ~9 months.

Everyone’s a user

My initial frustration was centered around what I saw as a reductive idea: only users who manually type in URLs will be affected. If you’re serving a static html webpage from the microservice with some supporting REST controllers, anyone trying to navigate to the webpage is a user. At first blush, that’s who the contributor was referring to right?

What about the developers though? Spring’s users are any developers using their framework, but its also any developer developing against a Spring application. They’re users who misunderstand things and lazily type URLs and throw tantrums when things don’t work as expected. You can trust them to append a path argument to the base URL but did they bother adding the six characters whose absence will irreparably harm them, + "/";?

• roll 6 sided dice
• 3 or higher, continue
• 2 or below, -5 hours of their lives and add one straw to the camels back

You don’t even have to be using the specific framework this change was made in for this change to affect you as a user. If you’re interacting with a Spring microservice, whether you know it or not, the trailing / matters. Flip a coin to determine if the developer who designed the API included the trailing /.

Your users are your users, and your users’ users, and your users’ users’ users, but that’s as far as I can go here without the stack tipping over.

Intermission

This is my second attempt writing about this. For the first draft, I attempted to frame this around poor planning and ill-communicated intentions. For some reason, I was unable to send my anecdotes down from on high and not sound like a self-righteous asshole. Once I determine what brought me back down to earth, I will attempt to bottle it and sell it.

Who are my users

At the time of writing, I’ve worked on a platform and infrastructure development team for seven years. One of the applications I support is an event based message routing server. It is user facing but is more heavily used by other applications for sending notifications. They provide us with data, the user provides the template, we fill in the blanks on said template, and fire the notification.

When our server doesn’t send out an email with the correct data, we’re the first stop for Support. It’s frustrating. It feels like getting yelled at by a customer at Arby’s because the sandwich artist who put the roast beef on the bun only included one piece of swiss when the customer specifically told me he wanted two. (Was that customer my user?)

I’ve usually only considered one user at my job, the person interacting directly with what the application produces or presents. We’ve had plenty of asks from project managers that were considering our Support people. They were even worded as “Hey can you add X? It will head off a lot of Support questions.” For the amount of time I spend talking with our Support about the features I’ve worked on, I should have been considering them during implementation as well. Better error messages, more documentation, actual tools for

Minor fixation

I don’t think I’ve spent so much time thinking about a comment I’ve read on the internet. This might be the first time I’ve seen an objection I agreed with, one based on an entrenched opinion, explained so easily away. It felt like an injustice after I found out why my client path wasn’t matching my server path.

This came back to mind when I started applying for backend software engineering jobs. Reading resume examples with flowery verbiage about how they improved a user’s engagement and experience. “X is a stupid use case, why don’t they just Y and Z” is something I’m guilty of replying to feature requests with. I don’t think I’ve ever done so in an open forum, but I rarely step back from my position and think about how “X” impacts user experience.

While I’m at this turning point in my career, if I continue to be so flippant about what users ask for, I’m not sure how I’ll be successful in finding a new job or even releasing my own user focused projects. “Its fine as long as people don’t use it” sounds like wishful thinking for software purgatory.

I found myself fascinated with his creative fixations… and felt like the only way to engage with that honestly was to expose all my own fixations, insecurities, and fears.

– Dan Olson - Folding Ideas - I Don’t Know James Rolfe