> Client applications would not need to be hard-coded with any domain-specific knowledge of the server-side APIs they interact with. Instead, they would discove

> Client applications would not need to be hard-coded with any domain-specific knowledge of the server-side APIs they interact with. Instead, they would discover all the available resources and operations dynamically, at runtime. A client application developed for one hypermedia API could be easily forked and modified for another hypermedia-driven web service. And "smart clients", which are capable of consuming any hypermedia API with a common grammar, could become a reality. This is WSDL and WADL, basically, except there's no common grammar to render a usable interface. The only real thing like what is described is a browser. If you want a universal interface, you make a web app, and the browser is the universal UI. Otherwise you just make a crappy console app and a crappy custom protocol using a HTTP API (or if you hate compatibility, simplicity and convenience: gRPC). To answer the poster's question, no, we're not going to rebrand REST. There are tons of improperly used terms that have been around for ages, they do not get rebranded. You just have to make a new thing and give it a new name and hope that it too isn't misused. ("DevOps" is the most glaring example to me, but also add "hacker", "crypto", "web", "cloud", "container", etc)