是否使用多种方法在RESTful POST中发送信息的反模式

此SO answer彻底检查了在RESTful POST方法中传递和访问参数的所有可能方法。是否使用多种方法在RESTful POST中发送信息的反模式

是否使用多种方法的反模式？

例如，你会考虑以下方法在POST HTTP方法的内容主体中传递JSON对象，并且还使用路径参数反模式？

@POST 
@Path("/modifyPerson/{idx}") 
@Consumes(MediaType.APPLICATION_JSON) 
public Response modifyPerson(Person newPerson, @PathParam("idx") int i) { 
    // ... 
}

我可以创建更丰富的类（例如PersonWithIdx），其结合了Person和idx整数参数，并传递代替无需求助于路径参数。上面的代码购买的唯一的东西是它避免了创建这个额外类的需要。但它听起来吗？

来源

2016-07-25 Marcus Junius Brutus

路径参数只能用于标识资源，不用于传递数据。如果你认为这个标识符是数据，那么我想你会在这个意义上使用两种方法。但我不认为它是数据 –

对我来说，这完全是一个判断呼吁......你的工程决定。如果它很有用，比如负载均衡或者你有什么用处，可以将URL中的信息基本上包含到*分类* URL中，或者指定（仅针对一个仅考虑URL的软件）这个* URL应该是什么你也可以把这些信息放在那里“。但是，如果您的API“消耗JSON”，我建议“JSON应该是它接收信息的唯一途径。” （当然，验证URL中的任何附属信息与JSON所说的一致，作为错误检查。）模式是指导原则。 –

是否使用多种方法的反模式？

号

例如你会考虑的是，在POST HTTP方法的内容主体传递JSON对象以下方法，并且还使用路径参数反模式？

号

如果你有大量的共享相同的底层实现，然后使用UriTemplate来识别这些信息如何消费特定的HTTP请求是适当的资源。

我可以创建更丰富的类（例如PersonWithIdx），其结合了Person和idx整数参数，并传递代替无需求助于路径参数。上面的代码购买的唯一的东西是它避免了创建这个额外类的需要。但它听起来吗？

从URI中取出标识符以将它们打包到请求体中听起来更像RPC而不是听起来像REST。

来源

2016-07-25 19:09:19 VoiceOfUnreason

是否使用多种方法在RESTful POST中发送信息的反模式

回答

相关问题