I'm pretty sure that this could have been successfully challenged if you didn't use the exact same URL schema, but I'm sure it would be pretty intimidating to square up against the IBM legal department.
For the most part (I'm not saying all) software patents seem to be more "method to achieve an outcome" rather than "here's a new idea that I want to protect". You shouldn't be able to say "I used this method to achieve a part of a larger goal, I thought of it first, nobody should be able to do the same thing".
Very rarely do software parents cover the actual final product someone is trying to sell, rather some of the intermediate steps they used to get there.
I think software patents only cover a very specific solution to some problem, not just any algorithm. For example, Simplex Noise used to be patented, while FFT never was.
It depends. Some patents are stupidly vague and either because of corruption (we'll take anybody's money) or they just plain don't understand software development, are granted.
The way software is built and used is completely different from the physical systems patents deal with. A lot of times it comes down to an algorithm or mathematically structure, which you're not supposed to be able to patent.
If you want to defend your super secret new algorithm from other companies, copyright your code and keep it closed source instead.
If you abolish patents, then nobody with a brain is going to invest the time and money into difficult R&D for any product that is easily duplicated/mass produced once invented.
People invented things before patents were a thing. People in China still invent stuff. People in America still invent stuff despite Chinese companies stealing much of the IP.
The fact of the matter is patents are not necessary for innovation, at least not universally. They may function as an accelerator, but at the same time they can slow it down by preventing others from improving on patented ideas for decades.
They can provide a crucial value by making foundational research and new markets economically viable, but so can state subsidies and state-funded research.
You’re making the assumption that innovation occurs in a silo, that the intrinsic motivation to create and send to market relies solely on a legal body dictating you’re the only one allowed to do so. As the other Redditor said, that belief is evidently false.
Many things cannot be kept closed-source. A program written in a scripting language (e.g. a website) can always be read by customers. Even compiled programs can often be reverse engineered.
Then you still have copyright. If you suspect someone stole your easily visible code, then just go look at their easily visible code and see if its the same, and sue.
In the case that they obfuscated it enough after they stole it to avoid copyright issues, it probably wouldn't be in danger of violating a patent anyway.
So, for starters, there are no such thing as software patents. What you have is a business process patent. These were originally created to protect things that were novel but didn’t constitute an invention- come up with a specialized process for running your fast food restaurant? Patent it instead of making it a trade secret.
Software patents are just business process patents with a computer involved.
And the problem with them specifically is part of a broader problem with patents: they’re frequently overly broad or are granted without regards to prior art. The legal system advantages the holder of the patent, making it expensive to defend against even bullshit claims.
A good (non-software) example is Magic the gathering. It has a mechanic in the game called “tapping”. You show a card has used its ability by tilting it. This was patented. Magic is not the first game to ever do that. It’s also a trivial invention. “Tilt a card to indicate status” likely doesn’t rise to the level of patentable. But they got the patent, and they enforced it. Which is why for like twenty years games said “exhaust” a card but didn’t specify how to do that exactly to avoid running afoul of the patent.
Many software patents are similar, but the thing with software is it’s easy to do at scale and exploit blind spots in the patent process. People have used patents on “sending an encrypted message” and “transmit video over an IP network” to go after business and it created an entire ecosystem of patent trolls. See also SCO, which tried to use patents to take down Linux.
To be perfectly honest, most patents are bullshit.
The problem with software patents specifically is that software has been an extremely fast growing industry within our lifetime, so most of the bullshit software patents aren't expired yet, while most other industries have already gone through their "bullshit patents avalanche" phase decades or centuries ago.
It kind of hurts me to think that this isn’t obvious to anyone who has ever built anything on the internet. The amount of gymnastics that JS frameworks go through to mimic actual URL changes is comical.
That's the danger of SPA. Yeah, there's benefits in terms of interactivity and responsiveness, but you kind of have to reinvent much of the wheel, or the browser, as it were. Lots of SPA stuff (or heavily JS stuff, generally speaking) doesn't handle back/forward correctly, doesn't restore state from history, doesn't let you open a link in a different tab, and so on.
React doesn't have anything to do with anchor tags, hrefs or browser location changes. Maybe you're thinking of a specific router library or framework?
I don't mean the language, I mean the ecosystem. React router and what have you. Single page routing means default browser mechanics like scrolling to an id on load can't work.
Again, the problem you're describing isn't the thing you're blaming it on. Dynamic content- the element with the id not existing on the page until after the scrolling would have happened- has been a problem since web 2.0 and the rise of ajax for delivering content.
Ironically, react spa frameworks that offer server side rendering are in the best position to fix that problem compared to others like angular.
That's fair, it's been ages since I looked at it, and it definitely didn't at the time. Vue does as well, which seems to render the original complaint even more moot.
You can make the same mistakes in a multipage app. Good practice in an SPA is to use a router, update the URL as you navigate and load the path appropriately when you return.
You can make the same mistakes in a multipage app.
If you use JS to overwrite how the history works, yes (in which case you pretty much have an SPA, or some kind of hybrid). But generally speaking, no; the browser already implements all that. Going back, going forward, bookmarks, opening URLs in tabs, is all stuff browsers have had built in for decades; you don't have to worry about them at all as a web developer unless you override the behavior, in which case see my original point.
From experience (I am writing one such library/framework in js, a port of a go wasm one I've just finished), the concerns above are really not difficult to handle. (easily said in hindsight perhaps)
The main issue I am encountering is state management, especially without wrecking perf. But that's just because of reactivity and me being uncompromisingly a runtime js framework. Getting there though.
The other candidates I would agree on but on this one I'm quite sceptical. Especially since the author posits this:
If you are not sure if a piece of state belongs in the URL, ask yourself: If someone else clicking this URL, should they see the same state?
Arguably, theming information should always stay local to the device - for example, if someone who's using a high-contrast theme shares a link (which contains a ?theme=highcontrast or something similar) to someone, why should that override the second person's theming preferences?
How you view content is your own. I'm not sharing my vscode themes at a repo level or forcing them to use my precise set of fonts and settings because they'd have configured it their own way. Saying themes and view modes should be in URL state is complete nonsense
Same with feature flags and A/B testing cause why would I want to expose that information to the user and set the experience for other users in the case of shareable content when they're not part of the test? Also putting that shit in the URL means the user can manipulate those flags which is a whole another can of worms
The article has a great point about URL being state and a lot of apps ignore this but this is kind of dumb
Enforcing workspace settings sometimes makes sense if you need to have a bunch of special stuff configured. I wish there was some way to have repo settings in vscode which take last priority vs workspace and user settings.
There's extension recommendations on a workspace level that you can check in to git and such but ideally you shouldn't be adding themes, fonts and icon extensions to that list. For eg. in JS projects you could add the "sort imports" extension or something
It should be in neither, it's automatically managed by the browser and OS already, all that needs to be done is to implement the appropriate css selectors.
The ideal situation would be for your web app to get permission to write on the disk. Then you create a file called “light_mode_on” or “dark_mode_on”, depending on the current mode. And then you read the file name to decide what to show the user.
You also have to worry about malicious hackers trying to trick you, so maybe the content of the file should be an encrypted and salted information you can validate.
List/grid would be ok, but it should be selectable via a share button or something. It is very useful to send people links where the data is in the format that you’re talking to them about. This is very selective, though, and has a very limited use case. Ie: a game site where you can view stats in different ways, include a share button that puts the current layout/view state in the url. Make it explicit.
I'd even extend this to form data, the thing that got the author excited about URL state in the first place.
User expectations around form data can vary and sometimes it makes more sense to keep form data ephemeral (as is the default), sometimes it makes sense to put it in a "Share Configuration" button.
If I can't paste your URL into my browser and get to the page I copied it from, I will silently curse you and try to avoid your website.
I'm not even talking about storing your entire state in the URL like this article does - that's certainly welcome, but many websites nowadays don't even store what page you were on in the URL.
My Visual Subnet Calculator preserves security by not actually having a database, it’s just their IP config encoded in the URL so they can bookmark it or share it with others. https://visualsubnetcalc.com
Also I had the idea of a password sharing service which would just basically provide an interface for generating an encrypted parameter in the URL and then allow you to decode it with the same passphrase. Basically a “clickable” way to decrypt a string.
I hear what you're saying, but... I work on a product that has a report system. The report has a decent chunk of its state in the URL. A LOT of people bookmark multiple different reports specifically because the state is in the url.
Basically... if you're doing state in the URL correctly, it's a feature of the page you're bookmarking, not an inconvenience.
depending on how much state it is you might be better off generating a short ID from a "share" button and storing the state server-side. Or do what many at my employer do and combine URL state with a link shortener 😂
no, and since you don't have to make a post via the bsky appview it wouldn't be that useful (also you can make posts without contacting bluesky at all, people on other PDSes might not want their links to be tracked, etc)
I also like that the query params has its own class, so you can use it on a query string in the hash like new URLSearchParams(document.location.hash.substring(1))
For an airline, there is a whole process for finding flights, using multiple steps, searches and selections. I however realized that at the end of this process, we basically have:
number of adults, children and babies flying
(a date + origin + flight number) x (1...6) ... depends on the number of legs the trip consists of
a final destination
We zipped this information (using a fixed dictionary not encoded in the URL), base64'd it, and signed it with a few chars. This is put in each URL (we used HATEOAS as well so we could modify this format as we pleased).
End result: fully stateless calls (50-100 over the course of finding your flight). No session timeouts - if we could still find the referenced flights after a couple of days, you can just resume where you left off. No session information at all aside from doing sticky sessions to direct calls to the same instance.
It's super powerful, and makes me sad that we have some 2k limit on URL's so we can't do this everywhere...
This article just reminded me. I once workd on a platform that put its session id within the uri. That was interesting when talking about search engines.
CoffeeStax@reddit
IBM once sued my employer for violating their patent on "keeping state in a URL."
djchateau@reddit
Putting state in a URL parameter is just the worst and feels really lazy, not to mention the URL gore that comes with it.
paholg@reddit
What an insane patent. I know all software patents are bullshit, but that one just seems excessively so.
Hot-Employ-3399@reddit
Samsung patented black mirrorish ad view for games where you need to throw (virtual) pickles and scream what is being advertised.
CherryLongjump1989@reddit
IBM is famous for obtaining an huge numbers of of patents. The vast majority of them are necessarily bullshit.
jessepence@reddit
I'm pretty sure that this could have been successfully challenged if you didn't use the exact same URL schema, but I'm sure it would be pretty intimidating to square up against the IBM legal department.
DottoDev@reddit
At least it would not be Oracles legal department
remy_porter@reddit
Oracle may be more overtly evil, but IBM has a much longer history and knows the ways of evil like none other.
New-Anybody-6206@reddit
we need to abolish software patents
Kenny_log_n_s@reddit
Why are software patents different than any other patent?
mrcarruthers@reddit
For the most part (I'm not saying all) software patents seem to be more "method to achieve an outcome" rather than "here's a new idea that I want to protect". You shouldn't be able to say "I used this method to achieve a part of a larger goal, I thought of it first, nobody should be able to do the same thing".
Very rarely do software parents cover the actual final product someone is trying to sell, rather some of the intermediate steps they used to get there.
Fupcker_1315@reddit
I think software patents only cover a very specific solution to some problem, not just any algorithm. For example, Simplex Noise used to be patented, while FFT never was.
mrcarruthers@reddit
It depends. Some patents are stupidly vague and either because of corruption (we'll take anybody's money) or they just plain don't understand software development, are granted.
Schmittfried@reddit
That’s exactly the point of patents though. They just suck, and it’s more noticeable in software due to the huge sharing economy.
goldman60@reddit
It's like building a novel folding coffee table and then patenting the use of wood in table construction
Norphesius@reddit
The way software is built and used is completely different from the physical systems patents deal with. A lot of times it comes down to an algorithm or mathematically structure, which you're not supposed to be able to patent.
If you want to defend your super secret new algorithm from other companies, copyright your code and keep it closed source instead.
teleprint-me@reddit
If I remember correctly, patents can not apply to a common interface or common mode of operation.
That's why algorithms are harder to enforce pantent-wise. There's very few ways to redo it if it's even possible at all.
So, patenting an equation is a no-op. Patenting an entire architecture is probably more feasible than say a single feature.
Personally, I think patents should be abolished in general. You effectively have a legal market monopoly on an idea.
Ideas are rarely ever unique and often inspire improvements later on if allowed, but more often patents just kill ideas in their crib.
dubious_capybara@reddit
If you abolish patents, then nobody with a brain is going to invest the time and money into difficult R&D for any product that is easily duplicated/mass produced once invented.
Schmittfried@reddit
That is evidently false.
dubious_capybara@reddit
How
Schmittfried@reddit
People invented things before patents were a thing. People in China still invent stuff. People in America still invent stuff despite Chinese companies stealing much of the IP.
The fact of the matter is patents are not necessary for innovation, at least not universally. They may function as an accelerator, but at the same time they can slow it down by preventing others from improving on patented ideas for decades.
They can provide a crucial value by making foundational research and new markets economically viable, but so can state subsidies and state-funded research.
chicknfly@reddit
You’re making the assumption that innovation occurs in a silo, that the intrinsic motivation to create and send to market relies solely on a legal body dictating you’re the only one allowed to do so. As the other Redditor said, that belief is evidently false.
which1umean@reddit
Imo something closer to copyright could add enough friction that it still boosts rents without grinding things to a hault with an absolute monopoly.
Also, there should be Harberger Taxes on patents (less than 100%, but more than 0% of rent should be socialized).
Without any kind of protection, there's still usually going to be enough stickiness to collect Schumpetarian Rents.
Ginden@reddit
Parents are explicitly monopolies, not only effectively, and they were developed specifically to allow rent extraction to incentivise R&D.
Though, American patent system is known to be a cesspool and enables patent trolling.
A1oso@reddit
Many things cannot be kept closed-source. A program written in a scripting language (e.g. a website) can always be read by customers. Even compiled programs can often be reverse engineered.
Fupcker_1315@reddit
Frontend code can absolutely be kept closed-source using minification/obfuscation. It isn't really that different from native executables.
Norphesius@reddit
Then you still have copyright. If you suspect someone stole your easily visible code, then just go look at their easily visible code and see if its the same, and sue.
In the case that they obfuscated it enough after they stole it to avoid copyright issues, it probably wouldn't be in danger of violating a patent anyway.
cusco@reddit
Because not everyone did understand what software was when they were created.
For instance, can you patent a math equation? Well that is what the patent on the voice codec g729 is.
the_bighi@reddit
They’re soft.
FyreWulff@reddit
A regular patent is being able to protect the design of your machine that lays down a new road surface faster than manually doing it.
A software patent is being able to give only yourself the right to make roads.
remy_porter@reddit
So, for starters, there are no such thing as software patents. What you have is a business process patent. These were originally created to protect things that were novel but didn’t constitute an invention- come up with a specialized process for running your fast food restaurant? Patent it instead of making it a trade secret.
Software patents are just business process patents with a computer involved.
And the problem with them specifically is part of a broader problem with patents: they’re frequently overly broad or are granted without regards to prior art. The legal system advantages the holder of the patent, making it expensive to defend against even bullshit claims.
A good (non-software) example is Magic the gathering. It has a mechanic in the game called “tapping”. You show a card has used its ability by tilting it. This was patented. Magic is not the first game to ever do that. It’s also a trivial invention. “Tilt a card to indicate status” likely doesn’t rise to the level of patentable. But they got the patent, and they enforced it. Which is why for like twenty years games said “exhaust” a card but didn’t specify how to do that exactly to avoid running afoul of the patent.
Many software patents are similar, but the thing with software is it’s easy to do at scale and exploit blind spots in the patent process. People have used patents on “sending an encrypted message” and “transmit video over an IP network” to go after business and it created an entire ecosystem of patent trolls. See also SCO, which tried to use patents to take down Linux.
jess-sch@reddit
To be perfectly honest, most patents are bullshit.
The problem with software patents specifically is that software has been an extremely fast growing industry within our lifetime, so most of the bullshit software patents aren't expired yet, while most other industries have already gone through their "bullshit patents avalanche" phase decades or centuries ago.
hammer-jon@reddit
because they affect ME
the_bighi@reddit
Abolish every patent.
jimbojsb@reddit
It kind of hurts me to think that this isn’t obvious to anyone who has ever built anything on the internet. The amount of gymnastics that JS frameworks go through to mimic actual URL changes is comical.
chucker23n@reddit
That's the danger of SPA. Yeah, there's benefits in terms of interactivity and responsiveness, but you kind of have to reinvent much of the wheel, or the browser, as it were. Lots of SPA stuff (or heavily JS stuff, generally speaking) doesn't handle back/forward correctly, doesn't restore state from history, doesn't let you open a link in a different tab, and so on.
Nixinova@reddit
One thing that's annoyed me recently is there's no way to use anchor hrefs in react.
anon_cowherd@reddit
React doesn't have anything to do with anchor tags, hrefs or browser location changes. Maybe you're thinking of a specific router library or framework?
Nixinova@reddit
I don't mean the language, I mean the ecosystem. React router and what have you. Single page routing means default browser mechanics like scrolling to an id on load can't work.
anon_cowherd@reddit
Again, the problem you're describing isn't the thing you're blaming it on. Dynamic content- the element with the id not existing on the page until after the scrolling would have happened- has been a problem since web 2.0 and the rise of ajax for delivering content.
Ironically, react spa frameworks that offer server side rendering are in the best position to fix that problem compared to others like angular.
TScottFitzgerald@reddit
Angular has SSR
anon_cowherd@reddit
That's fair, it's been ages since I looked at it, and it definitely didn't at the time. Vue does as well, which seems to render the original complaint even more moot.
hyrumwhite@reddit
You can make the same mistakes in a multipage app. Good practice in an SPA is to use a router, update the URL as you navigate and load the path appropriately when you return.
chucker23n@reddit
If you use JS to overwrite how the history works, yes (in which case you pretty much have an SPA, or some kind of hybrid). But generally speaking, no; the browser already implements all that. Going back, going forward, bookmarks, opening URLs in tabs, is all stuff browsers have had built in for decades; you don't have to worry about them at all as a web developer unless you override the behavior, in which case see my original point.
aatd86@reddit
it's not really the SPA model that is the issue. It's just some of the frameworks which don't handle it appropriately.
The same way it could be easy to persist state across MPA navigations but it isn't done by default (except for the bfcache).
The browser provides the tool but it's up to people to actually use them.
Schmittfried@reddit
The point is that SPAs require overriding the browser‘s behavior in the first place, so implementing a functioning SPA framework is harder.
aatd86@reddit
From experience (I am writing one such library/framework in js, a port of a go wasm one I've just finished), the concerns above are really not difficult to handle. (easily said in hindsight perhaps) The main issue I am encountering is state management, especially without wrecking perf. But that's just because of reactivity and me being uncompromisingly a runtime js framework. Getting there though.
nemec@reddit
looking at you, banks who invalidate your session if you click Back
lord2800@reddit
You mean
history.pushState()and a web server configured to route everything to the front door? Not exactly rocket science nor even complicated...Schmittfried@reddit
And yet so many websites fail at it in several different ways.
lord2800@reddit
I'm not saying they don't. I'm saying the solution is dead simple, and there isn't a lot of gymnastics one has to jump through to do it.
You can lead a horse to water, but you can't make it drink.
mattgrave@reddit
I have worked with hunders of react devs that dont know that shit and overcomplicate that stuff because they dont fucking know the platform
lord2800@reddit
That's a problem of react/react devs, not a problem of the web platform as a whole.
seven_seacat@reddit
Same, but its also a good refresher/summary for newer folk.
Gipetto@reddit
I’m working on a site know where there’s push back to storing view state in the url. It is quite maddening.
in2erval@reddit
The other candidates I would agree on but on this one I'm quite sceptical. Especially since the author posits this:
Arguably, theming information should always stay local to the device - for example, if someone who's using a high-contrast theme shares a link (which contains a
?theme=highcontrastor something similar) to someone, why should that override the second person's theming preferences?aniforprez@reddit
How you view content is your own. I'm not sharing my vscode themes at a repo level or forcing them to use my precise set of fonts and settings because they'd have configured it their own way. Saying themes and view modes should be in URL state is complete nonsense
Same with feature flags and A/B testing cause why would I want to expose that information to the user and set the experience for other users in the case of shareable content when they're not part of the test? Also putting that shit in the URL means the user can manipulate those flags which is a whole another can of worms
The article has a great point about URL being state and a lot of apps ignore this but this is kind of dumb
slaymaker1907@reddit
Enforcing workspace settings sometimes makes sense if you need to have a bunch of special stuff configured. I wish there was some way to have repo settings in vscode which take last priority vs workspace and user settings.
aniforprez@reddit
There's extension recommendations on a workspace level that you can check in to git and such but ideally you shouldn't be adding themes, fonts and icon extensions to that list. For eg. in JS projects you could add the "sort imports" extension or something
the_bighi@reddit
Dark and light should not be in the URL.
Thats a very good use case for the local storage options that browsers offer.
camaris1234@reddit
It should be in neither, it's automatically managed by the browser and OS already, all that needs to be done is to implement the appropriate css selectors.
the_bighi@reddit
It depends on what you want from it. Hear me out.
The ideal situation would be for your web app to get permission to write on the disk. Then you create a file called “light_mode_on” or “dark_mode_on”, depending on the current mode. And then you read the file name to decide what to show the user.
You also have to worry about malicious hackers trying to trick you, so maybe the content of the file should be an encrypted and salted information you can validate.
Hackers are no joke.
Gipetto@reddit
100%
Don’t force me in to a different light/dark mode.
List/grid would be ok, but it should be selectable via a share button or something. It is very useful to send people links where the data is in the format that you’re talking to them about. This is very selective, though, and has a very limited use case. Ie: a game site where you can view stats in different ways, include a share button that puts the current layout/view state in the url. Make it explicit.
lotgd-archivist@reddit
I'd even extend this to form data, the thing that got the author excited about URL state in the first place.
User expectations around form data can vary and sometimes it makes more sense to keep form data ephemeral (as is the default), sometimes it makes sense to put it in a "Share Configuration" button.
lonewaft@reddit
I thought state was supposed to be in the cookies?
teppicymon@reddit
How many Rick Rolls did you spot? 2 for me.
And yes, I really did try to decode that!
ahmadalfy@reddit
The author is here; I am finally glad that someone found it
White_Town@reddit
My heart missed a beat with this subject because I’m building https://state.sk 😅
Reverent@reddit
Because there is a lot of confusion in the comments:
State is not the same thing as settings.
1668553684@reddit
If I can't paste your URL into my browser and get to the page I copied it from, I will silently curse you and try to avoid your website.
I'm not even talking about storing your entire state in the URL like this article does - that's certainly welcome, but many websites nowadays don't even store what page you were on in the URL.
SpectralCoding@reddit
My Visual Subnet Calculator preserves security by not actually having a database, it’s just their IP config encoded in the URL so they can bookmark it or share it with others. https://visualsubnetcalc.com
Also I had the idea of a password sharing service which would just basically provide an interface for generating an encrypted parameter in the URL and then allow you to decode it with the same passphrase. Basically a “clickable” way to decrypt a string.
AndrewNeo@reddit
arguably security would come via having it after the a hash, query parameters are still sent to the server
SpectralCoding@reddit
Yes the server would only see the encrypted string and never see the encryption key or passphrase. That would be all client side in JavaScript
ddollarsign@reddit
The more stuff stored in a URL, the more I have to strip off if I just want to bookmark the page.
chalks777@reddit
I hear what you're saying, but... I work on a product that has a report system. The report has a decent chunk of its state in the URL. A LOT of people bookmark multiple different reports specifically because the state is in the url.
Basically... if you're doing state in the URL correctly, it's a feature of the page you're bookmarking, not an inconvenience.
ddollarsign@reddit
With good design, it could definitely be useful.
nemec@reddit
depending on how much state it is you might be better off generating a short ID from a "share" button and storing the state server-side. Or do what many at my employer do and combine URL state with a link shortener 😂
NSRedditShitposter@reddit
I don’t like this because such URLs would be really difficult to share.
I don’t know why developers see URLs as an internal detail instead of an active part of the user interface.
nemec@reddit
does bluesky not do the link shortening thing twitter does? links on twitter haven't cost more than 20ish chars in years
AndrewNeo@reddit
no, and since you don't have to make a post via the bsky appview it wouldn't be that useful (also you can make posts without contacting bluesky at all, people on other PDSes might not want their links to be tracked, etc)
gimmeslack12@reddit
The URL constructor is one of my faves. It makes handling query strings quite easy.
Key-Celebration-1481@reddit
I also like that the query params has its own class, so you can use it on a query string in the hash like
new URLSearchParams(document.location.hash.substring(1))gimmeslack12@reddit
Love that one too!
drislands@reddit
.
Heh.
john16384@reddit
For an airline, there is a whole process for finding flights, using multiple steps, searches and selections. I however realized that at the end of this process, we basically have:
We zipped this information (using a fixed dictionary not encoded in the URL), base64'd it, and signed it with a few chars. This is put in each URL (we used HATEOAS as well so we could modify this format as we pleased).
End result: fully stateless calls (50-100 over the course of finding your flight). No session timeouts - if we could still find the referenced flights after a couple of days, you can just resume where you left off. No session information at all aside from doing sticky sessions to direct calls to the same instance.
It's super powerful, and makes me sad that we have some 2k limit on URL's so we can't do this everywhere...
gofl-zimbard-37@reddit
Bell Labs' Dave Korn (of ksh fame) was doing that kind of thing around 20 years ago. He was encoding all kinds of crazy stuff in there.
memoriesofgreen@reddit
This article just reminded me. I once workd on a platform that put its session id within the uri. That was interesting when talking about search engines.
gnahraf@reddit
I agree. My project Crums Timechain also doles out witness receipts as URLs, much for the same reasons you enumerate (bookmark, copy/paste, etc)