Maybe the article could have been more succinct with some SOA jargon but a service description language (WSDL) and service discovery system (UDDI) are important

Maybe the article could have been more succinct with some SOA jargon but a service description language (WSDL) and service discovery system (UDDI) are important and not really a well solved problem in practice despite the multitude of standards made back in the 90s. So, the question posed to me by the author is what has REST provided for us so far that we should continue to expand upon that it solves legitimate concerns of enterprise architectures. I can say for sure that UDDI failed in enterprise by now and with REST it really seems like we've stopped progress there anyway. Instead of either, everyone has moved to message passing architectures that accept the reality that services are extremely varied in maturity and semantics across the enterprise world. REST is about as vague of a standard as AMQP or even JMS as far as service standardizations and ontologies go. To me REST in enterprise is simply reflective of how broken SOAP and XML-RPC was in practice in enterprises and made for far too inflexible, monolithic services that'd take years to move forward major versions. You can decompose REST respurce URLs at least and try to scale out from there instead of being stuck to the service definition's XML schema for every resource definition. Sure, I've seen some Schemas that are composed but in the world of enterprise software vendors and internal bureaucratic services you will devolve to the pathological cases of simplicity in your architecture to get the bare minimum done, and REST works better in practice here than anything WS standards related.