Parameter passing at multiple levels:
As an example, Spring MVC binds similarly named request parameters (whether post body parameters or url query string parameters) to parameters on the controller method. That breaks the parameters out of their representation in the HTTP request and makes them reasonable Java parameters to a method. If you're passing data to services in your model from your controller there are three avenues of thought.
The first is to pass model objects which you fill out from the parameter data and pass them to your services. Given that you are probably using some sort of O/R mapper like JPA or Hibernate, you will need to merge those objects into the hibernate session or jpa persistence context. However, you have more tightly coupled your models to your controllers.
Second is to pass simple Java types to keep your services and your controllers more loosely coupled. For complex objects with several fields, this is a pain. Also, when you have several int parameters in a row, the chance you might flip two by accident is pretty good.
The third options is to define a data transfer object which is passed to the service method, which in turn manipulates your model. The DTO could contain fields that you might map to two or more objects in your model, but now your controller logic is only coupled to the DTO and you could still evolve your model independently of the Controller.
Okay, so that takes the data from HTTP land through the controller to your model. That's the current "best practice" way to build Java applications but may not be the best for your application. (However, it probably is since it works for a large majority of applications).
As far as where to put those values (request body or parameters) it might be helpful to think in terms of REST. Generally, when you have a form to add new data or to update data, you will send the parameters in the post body. You can think of operations as being "dangerous" (they alter the state of your application) or "safe" (they change nothing). (Note that incidental changes like logging don't count.) Operations can also be idempotent - meaning they can be executed more than once and the state of the system is the same as it was after the first invocation.
Dangerous, non-idempotent operations should be a POST. Dangerous but idempotent operations should be a DELETE or PUT. (Note that some browsers only support POST, so you can just stick with POST). The parameters should be encoded in the POST body. You generally wouldn't use query string parameters.
Safe, idempotent operations should be a GET. It is perfectly acceptable to encode additional parameters in the URL string to facilitate the operation of the GET. For example, if searching by the username, adding ?username=the+user as a query parameter is fine. Or to distinguish records ?id=23. Some people believe that URLs can be restful only if they include the identifying component as part of the document path /users/23, but I don't believe that's correct since /users?id=23 is just as unique as /users/23. (And I don't recall it from Fielding's dissertation - but I have lousy memory).