0

This SO answer thoroughly goes through all possible methods of passing and accessing parameters in a RESTful POST method.

Is it an anti-pattern to use more than one method?

For instance would you consider the following method that passes a JSON object in the content body of the POST HTTP method and also uses a path parameter an anti-pattern?

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

I could create a richer class (e.g. PersonWithIdx) that combines both Person and the idx integer parameter and pass that instead with no need to resort to path parameters. The only thing the above code buys me is that it obviates the need to create this extra class. But is it sound?

Community
  • 1
  • 1
Marcus Junius Brutus
  • 23,022
  • 30
  • 155
  • 282
  • 3
    The path parameter should only be used for identification of the resource, not for passing data. If you consider the identifier as data, then I guess yeah you would be using two methods in that sense. But I wouldn't consider it to be data – Paul Samsotha Jul 25 '16 at 16:58
  • 1
    To me, it is purely a judgment call ... an engineering decision on your part. If it is useful, say for load-balancing or what have you, to include information in the URL basically to *classify* the URLs or to specify (to a piece of software that's considering only the URL) how *this* URL should be served, you might put such information there "also." But, if your API "consumes JSON," I recommend that "JSON should be the only way that it receives information." (Of course, verify that any collateral information in the URL agrees with what the JSON says, as a bug-check.) Patterns are GUIDELINES. – Mike Robinson Jul 25 '16 at 17:05

1 Answers1

1

Is it an anti-pattern to use more than one method?

No.

For instance would you consider the following method that passes a JSON object in the content body of the POST HTTP method and also uses a path parameter an anti-pattern?

No.

If you have a large number of resources that share the same backing implementation, then using a UriTemplate to identify how those messages consume a particular HTTP request is appropriate.

I could create a richer class (e.g. PersonWithIdx) that combines both Person and the idx integer parameter and pass that instead with no need to resort to path parameters. The only thing the above code buys me is that it obviates the need to create this extra class. But is it sound?

Taking identifiers out of the URI to pack them into the request body sounds more like RPC than it sounds like REST.

VoiceOfUnreason
  • 40,245
  • 4
  • 34
  • 73