What is the proper way to pass the parameters into a MVC system?

Question

I am trying to learn java servlet/jsp with the MVC concept and built the simplest MVC application. Now I want give more detail to it to enhance my understanding.

If I would need to register a new row in a table in the database, how should we pass the various value of column into the system?

For example, the user might want to register a new event in his planner and the detail of the event involves the 'where', 'when', 'who', 'detail', etc. Should pass all this long value from the servlet's parameter, i.e: the http link?

String accNo = request.getParameter("account_number");
String a = request.getParameter("...");
String b = request.getParameter("...");
String c = request.getParameter("...");
String d = request.getParameter("...");

To illustrate my view that it is really unprofessional to show all the parameter on the link:

http://localhost:8080/domain1/servlet1?param1=55555555555555&param2=666666666666666666666666666666666666666666666666666666666666&param3='Some random detail written by user.........................'

Is there other way to pass them?

Answer 1

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).

Answer 2

Well, lets not mix concepts.

In one side...

MVC is a software architectural pattern. It can be applied to Desktop apps aswell, where HTTP is not necessarily involved.

In the other side...

HTTP is a comunication protocol. Like wikipedia say:

is an application protocol for distributed, collaborative, hypermedia information systems

So, you are asking if HTTP support any other way to pass information (parametrized) alternative to query strings

---

Request

HTTP Comunications are made in terms of Requests and Responses

In any request it's informed also a METHOD. It's just an instruction to the server-side application to tell what we expect server should do with the info we send. But it's not a mechanism to pass information. It's an additional instruction no more no less.

Beside methods, here we have 3 possible ways to pass parameters to the server

1. Query String

Method involved: GET

Info is informed (parametrized) into the URL. This's the example you exposed

http://localhost:8080/domain1/servlet1?param1=X&param2=X&param3='X'

Its capacity is limited to 64Kb (if memory serves). This's the basic way

2. BODY

Methods involved: POST|PUT

A message is expected into the body of the Request. This Message is known as payload,form,body but It can be also binaries. The format of the message can be xml,text plain,json,....

However, we still are able to pass info via query string in the same request. So part of the info is going to be in the URL and another part is going to be at request's body

Info here goes encrypted if we are working under SSL enviornment.

For basic information and tutorials, check out this link W3Schools - Html Forms. Take it as an example of how to send info via Forms from an html form.

3. HEADER

Methods involved: Any

Any Request from A to B (being B the server-side) has a header. Info here is not intended to be processed by your app's business. It's not data related to your business. However you can put info anyways. It's the place where security tokens are informed between a client and any securized API Rest. Plus some other parameters related to the environment and some parameters addressed to the web server. Also informs the content type expected in the response and also the content type of the info sent (xml, json, binary, multipart, etc..)

So yes there're some other ways to inform parameters to the server. But the way to implement such ways depends on your platform. There're many platforms and frameworks oriented to make this task easy. At this point we would need to know on what platform is your project running at. On which programming language is being built.

---

Finally I would like to point at Rest can not be described as a supported mechanism of HTTP protocol to pass info. It's a software architectural style.

It uses URL sintaxy to pass info, put It's a convention, not a mechanism of the protocol

---

To your answer

If I would need to register a new row in a table in the database, how should we pass the various value of column into the system?

The best way is going to be by: POST, using html forms. Check out W3schools - HTML Forms

Another way can be by: POST, using Ajax. This way has more complexity. But let you send an stack of changes in a single request. To do so via Html form is little bit more complicated.

Would be good to know which libraries or frameworks are you using in your project.

Note: It's intended in this post to make a brief, not a technical introduction to HTTP. Any fix or any better way to say what I tried to explain is wellcome.