No, the author is not confusing them. It’s everyone else that has been confused insofar as they use “REST” to describe APIs that are not actually REST. True REST is a way of architecting networked applications according to a set of constraints, as defined by Roy Fielding in his original dissertation. Here’s an excerpt that sums it up:
In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
Many “REST” APIs do not adhere to these constraints, especially self-descriptive messages and hypermedia as the engine of application state (also known as HATEOAS). Note that this says nothing about HTML: HTML is but one representation of hypermedia, but far from the only one. Hypermedia is something that allows discovery of additional, related resources by way of links between resources. There are a number of ways of doing this, such as RFC 8288 Link Headers or embedding links within one of a resource’s representations (such as a JSON representation).
It’s a much larger topic than I can fully explain here, but I highly recommend reading Roy Fielding’s dissertation, especially Chapter 5 which talks about REST and what it is.
I also highly recommend this blog post from Google Cloud’s engineering team, which talks about why you should use links instead of keys to represent relationships in API design: https://cloud.google.com/blog/products/application-development/api-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis.
Tired of this trope. Learning data structures and algorithms is not about memorizing the specifics of some particular algorithm. That’s like thinking that learning math is about memorizing formulas.
DS&A is about learning *algorithmic thinking" and how common data structures actually work, so you can begin to build a toolbox of things you can use when making your own data structures. Software engineers that are actually good know this shit backwards and forwards, because it does actually come up all over the place (and these are the kind of people that actually write libraries). Even the basic things you learn in school are actually incredibly useful for understanding the implementation details of databases and how query planners and indexes work, for example (very helpful when trying to understand query performance).
And don’t get me started on just how fucking much directed acyclic graphs come up in the real world. Git? DAG. Any package manager? DAGs. Nix? DAGs. Open Telemetry? DAGs (the main data structure is a tree which is a special case of DAGs, but if you use linked spans, it would form a DAG). Hell, I’m working on something right now that needs to be modeled as a DAG. It’s almost comical how useful they are.
We should be encouraging people to learn and grow more, not less.