我的后端应用程序需要三个参数来创建一个对象并将其作为JSON返回
http://server/app/resource.json?a=foo&b=3&c=bar
我的应用程序中有另一个功能可以从上面的URI返回并将其“转换”为另一个对象。现在，我正在做以下
http://server/app/resource.json?a=foo&b=3&c=frob&transform_to=blarg
这对我来说似乎不太直观。我想知道我是否可以做类似
的事情http://server/app/resource.json?in={a:foo,b:3,c:frob}&out={c:blarg}
对此有任何建议。
更有趣的是，如果我可以从一个URI获取输出并将其作为输入传递给另一个URI，但我想我们还有很长的路要走。
答案 0 :(得分：2)
在REST术语中，出于几个原因，你所做的事情是完全错误的。
我的应用程序中有另一个功能，它可以从上面的URI返回对象并将其“转换”为另一个对象。
您可以对单个资源进行多次表示，但将其“转换”为不同的对象已经意味着您正在谈论不同的资源。
要解决此问题，您至少需要创建不同的资源，这将产生不同的对象。例如：http://server/app/brag.json?a=foo&b=3&c=bar
http://server/app/resource.json?a=foo&b=3&c=frob&transform_to=blarg
您正在将操作（即transform_to）直接编码到URL中。这不是REST，这是非常常见的RPC。您需要依赖统一接口，并且在HTTP情况下仅使用GET / POST / PUT / DELETE方法（动词）。
同样，创建不同的资源，即接受查询参数的/blarg.json将更加清晰，您将避免在URL中传递操作。
http://server/app/resource.json?in= {一个：FOO，B：3，C：FROB}＆安培;列= {C：blarg}
这种参数“{a：foo，b：3，c：frob}”没有多大意义。如果您的后端系统知道它所依赖的参数，为什么不继续使用这种更清洁，更自然的方法呢？ “A = FOO和b = 3和C =栏”
在此示例中，将“＆amp; out = {c：blarg}”转换为“＆amp; format = blarg”将部分修复上述操作问题，但这仍然意味着您的资源有两个单一的变体（不是表示形式）媒体类型（在这种情况下为application / json）。这在逻辑上导致我们创建不同的资源，而不是将现有资源转换为不同的对象。
更有趣的是，如果我可以从一个URI获取输出并将其作为输入传递给另一个URI，但我想我们还有很长的路要走。
是的，它绝对合法，但这取决于您将如何实施此类行为。
=============================================== ============================================
在处理基于HTTP协议的RESTful Web服务时，主要目标是依赖HTTP语义，并始终避免在其上构建其他规则。 SOAP Web服务就是这方面的好例子（它并不意味着SOAP就是床等......）。 SOAP始终使用HTTP的POST方法与服务器通信，并以XML格式编码所有参数和操作。