One of the main properties of REST: "Each request from any client contains all the information necessary to service the request, and the session state is held in the client."

In practice, REST makes things like caching, load-balancing, and debugging easier at the cost of needing to send more state back and forth. In HTTP, there are ways to reduce or at least hide the repeated TCP handshakes.

But, again, if they're just sending up html that contains links etc, how is it not self-contained and restful?

I suspect we can't really get to the bottom of this, as we don't know exactly what they're doing.

The article links to a spec, and there are other implementations like this. If you consider this REST, what would you consider non-REST?

I dont get what you are arguing. If state lives on the server you have added complexity of holding state for every user. This is exactly what REST was designed to remove.

That's what I'm saying, the design in the article is not REST