UDDI可以用于REST服务。WSDL可以用来描述HTTP web服务，但坦率地说，我觉得它与REST资源体系结构并不匹配。
在最基本的层次上，UDDI只是将属性映射到服务端点。因此，如果您只是在寻找一个能够做到这一点的系统，那么UDDI将符合要求。
UDDI在狂野、开放的互联网中并不流行，但它被用作"幕后"的编排组件。
正如Darrel提到的，DNS是另一种有效的发现机制。
我个人对DNS的抱怨很简单，尽管DNS具有他引用的文章中提到的所有优点，但缺点是DNS是网络结构的关键部分，开发者往往无法使用它。通常，网络运营人员(他们往往比DBA更臭名昭著(非常接近DNS等基础设施。最后，虽然DNS能够完成这些任务，但在许多情况下，DNS的标准默认配置和部署可能需要更改。例如，我们已经开始从DNS提供证书，并且我们必须为DNS启用TCP。同样，这意味着网络运营的更多参与。
除此之外，虽然世界上有很多DNS的专业知识和知识，但HTTP和在网络服务器上"做事情"的知识和专业知识要多得多。这意味着，当开发人员思考并寻求某种解决方案时，他们首先要考虑的可能是基于HTTP的解决方案。
因此，从这个意义上说，UDDI可能是一个更好的解决方案，只需要能够轻松快速地推出它。
当然，UDDI是一种基于SOAP的服务。这没什么大不了的，真的。不太适合RESTful系统，但也不算糟糕。功能，如果有点"不纯"。
至于标准的基于HTTP的服务注册表，我一无所知。例如，简单地用HTML临时创建一个是合理的。UDDI并没有在世界范围内流行起来，这与其说是对UDDI的限制或轻视。相反，发现任意服务的愿景并没有真正实现，根本不存在这种需求。除了位置和语义之外，还有更多涉及带外服务发现的内容，比如业务关系等等。
在企业内部，这些物流都得到了解决，因此服务发现具有价值。在野外，没有那么多。
它没有死；(
- 签署了一个jUDDI开发人员juddi.apache.org
编辑：还有CXF和WCF都支持的WS-Discovery。值得一看。
FWIW，UDDIv3确实指定了一个REST接口，但我认为除了jUDDI之外，没有其他人实现过它。它将包含在v3.2及更高版本中，使用CXF、Jettison和WADL。来源：http://svn.apache.org/repos/asf/juddi/trunk/juddi-rest-cxf/src/main/java/org/apache/juddi/api/impl/rest/UDDIInquiryJAXRS.java
UDDI是为SOAP服务设计的，但它甚至不再用于这些服务。UDDI在2006年几乎已经消亡。
这篇文章展示了如何使用DNS进行发现。