关于REST的愚蠢问题

Question

1. REST是否可以纯粹用作轻量级SOAP替代品（不必担心名词和动词相关）？我真正讨厌SOAP的是它在消息有效负载方面增加的开销，我喜欢在REST中使用JSON，这应该让沟通变得简洁。

2. 为了便于客户端集成，从服务器向客户端提供定义的最佳方法是什么。阅读其他帖子post1 post2，似乎有很多不喜欢提供类似WSDL的替代方案（即WADL？）。如果服务器和客户端都知道可能发生的更改，并且我使用REST的原因只是上面的＃1，那么为什么这么糟糕呢？

Answer 1

  

REST是否可以纯粹用作轻量级SOAP替代方案（而不必担心与名词和动词相关）？

如果您仍想将其称为REST，则不会。 REST 按照定义关心名词和动词。如果您只想使用JSON来执行RPC，请继续。但你最终会被描述为“SOAP lite”。

  

为了便于客户端集成，从服务器向客户端提供定义的最佳方法是什么。阅读其他帖子post1 post2，似乎有很多不喜欢提供类似WSDL的替代方案（即WADL？）。如果服务器和客户端都知道可能发生的更改，并且我使用REST的原因只是上面的＃1，那么为什么这么糟糕呢？

WSDLish“定义”被认为是错误的，因为REST实际上并不是一种RPCish风格的协议。使用REST，您可以从单个入口点开始，然后在此处跟踪响应中服务器提供的URL。客户端不应该需要对方法调用具有“定义”等 - 标准HTTP动词应该具有标准，明显和适当的效果 - 并且它甚至不需要先前的知识如何构建URL;应在响应中提供URL。例如，如果您正在获取用户配置文件，则响应字段可能是该用户的URL。如果您正在查看订单，则其中的每个项目都会有一个URL（作为字段！），您可以使用该URL来检索该项目的信息。如此。