doGet et doPost en Servlets

Introduction

vous devez utiliser doGet() lorsque vous voulez intercepter sur les requêtes HTTP GET . Vous devez utiliser doPost() lorsque vous voulez intercepter sur les requêtes HTTP POST . C'est tout. Ne pas porter l'un à l'autre ou vice versa (comme dans la malheureuse méthode processRequest() de Netbeans). Cela ne fait pas de proférer des sens.

GET

habituellement, les requêtes HTTP GET sont idempotent . C'est-à-dire: vous obtenez exactement le même résultat à chaque fois que vous exécutez la requête (en laissant l'autorisation/authentification et la nature temporelle de la page-Résultats de recherche, dernières nouvelles, etc-considérations externes). Nous pouvons parler d'une demande bookmarkable. En cliquant sur un lien, En cliquant sur un signet, en entrant L'URL brute dans la barre d'adresse du navigateur, etcetera lancera une requête HTTP GET. Si un Servlet écoute L'URL en question, puis sa méthode doGet() sera appelée. Il est généralement utilisé pour préprocessus une requête. C'est-à-dire: faire des affaires avant de présenter la sortie HTML d'un JSP, comme rassembler des données pour les afficher dans un tableau.

@WebServlet("/products")
public class ProductsServlet extends HttpServlet {

    @EJB
    private ProductService productService;

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        List<Product> products = productService.list();
        request.setAttribute("products", products); // Will be available as ${products} in JSP
        request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response);
    }

}

<table>
    <c:forEach items="${products}" var="product">
        <tr>
            <td>${product.name}</td>
            <td><a href="product?id=${product.id}">detail</a></td>
        </tr>
    </c:forEach>
</table>

aussi voir/Modifier les liens de détails comme montré dans la dernière colonne ci-dessus sont généralement idempotent.

@WebServlet("/product")
public class ProductServlet extends HttpServlet {

    @EJB
    private ProductService productService;

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Product product = productService.find(request.getParameter("id"));
        request.setAttribute("product", product); // Will be available as ${product} in JSP
        request.getRequestDispatcher("/WEB-INF/product.jsp").forward(request, response);
    }

}

<dl>
    <dt>ID</dt>
    <dd>${product.id}</dd>
    <dt>Name</dt>
    <dd>${product.name}</dd>
    <dt>Description</dt>
    <dd>${product.description}</dd>
    <dt>Price</dt>
    <dd>${product.price}</dd>
    <dt>Image</dt>
    <dd><img src="productImage?id=${product.id}" /></dd>
</dl>

POST

les requêtes HTTP POST ne sont pas idempotent. Si l'utilisateur final a soumis un formulaire de POST sur une URL à l'avance, qui n'a pas effectué une redirection, alors L'URL n'est pas nécessairement bookmarkable. Les données du formulaire soumis ne sont pas reflétées dans L'URL. Le copyptage de l'URL dans une nouvelle fenêtre/Onglet de navigateur ne donne pas nécessairement le même résultat qu'après la soumission du formulaire. Une telle URL n'est alors pas bookmarkable. Si un Servlet écoute sur L'URL en question, alors son doPost() s'appellera. Il est généralement utilisé pour postprocess une requête. C'est-à-dire: collecter des données à partir d'un formulaire HTML soumis et faire des affaires avec (conversion, validation, sauvegarde dans DB, etcetera). Enfin généralement le résultat est présenté en HTML à partir de la page JSP transmise.

<form action="login" method="post">
    <input type="text" name="username">
    <input type="password" name="password">
    <input type="submit" value="login">
    <span class="error">${error}</span>
</form>

...qui peut être utilisé en combinaison avec ce morceau de Servlet:

@WebServlet("/login")
public class LoginServlet extends HttpServlet {

    @EJB
    private UserService userService;

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String username = request.getParameter("username");
        String password = request.getParameter("password");
        User user = userService.find(username, password);

        if (user != null) {
            request.getSession().setAttribute("user", user);
            response.sendRedirect("home");
        }
        else {
            request.setAttribute("error", "Unknown user, please try again");
            request.getRequestDispatcher("/login.jsp").forward(request, response);
        }
    }

}

vous voyez, si le User est trouvé dans la base de données (c.-à-d. que le nom d'utilisateur et le mot de passe sont valides), alors le User sera mis dans la portée de session (c.-à-d. "connecté") et le servlet redirigera vers une page principale (cet exemple va à http://example.com/contextname/home ), sinon il définira un message d'erreur et transmettra la demande de nouveau à la même page JSP de sorte que le message soit affiché par ${error} .

vous pouvez si nécessaire aussi "cacher" le login.jsp dans /WEB-INF/login.jsp de sorte que les utilisateurs ne peuvent y accéder par le servlet. Cela maintient L'URL propre http://example.com/contextname/login . Tout ce que vous devez faire est d'ajouter un doGet() pour la servlet comme ceci:

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);
}

(et mettre à jour la même ligne dans doPost() en conséquence)

cela dit, Je ne suis pas sûr si c'est juste jouer et tirer dans le noir, mais le code que vous avez posté n'a pas l'air bien (comme utiliser compareTo() au lieu de equals() et creuser dans les noms de paramètres au lieu d'utiliser simplement getParameter() et id et password semble être déclaré comme des variables d'instance de servlet - qui N'est pas threadsafe ). Je recommande donc fortement d'en apprendre un peu plus sur L'API Java SE de base en utilisant les tutoriels Oracle (consultez le chapitre "Trails Covering the Basics") et comment utiliser JSP/Servlets de la bonne manière en utilisant ces tutoriels .

voir aussi:

• nos servlets wiki page
• Java EE développement web, où dois-je commencer et quelles compétences ai-je besoin?
• Servlet renvoie "d'État HTTP 404 La ressource demandée (/servlet) n'est pas disponible"
• afficher les résultats JDBC en HTML dans la page JSP en utilisant MVC et le motif DAO

---

mise à jour : selon la mise à jour de votre question (qui est assez importante, vous ne devriez pas supprimer des parties de votre question originale, cela rendrait les réponses sans valeur .. plutôt ajouter l'information dans un nouveau bloc) , il s'avère que vous mettez inutilement le type d'encodage du formulaire à multipart/form-data . Ceci enverra les paramètres de la requête dans un autre composition que le application/x-www-form-urlencoded (par défaut) qui envoie les paramètres de la requête sous forme de chaîne de requête (par exemple name1=value1&name2=value2&name3=value3 ). Vous n'avez besoin de multipart/form-data que lorsque vous avez un élément <input type="file"> dans le formulaire pour télécharger des fichiers qui peuvent être des données sans caractère (données binaires). Ce n'est pas le cas dans votre cas, il suffit donc de retirer et il va fonctionner comme prévu. Si vous avez besoin de télécharger des fichiers, alors vous devrez définir le type d'encodage so et analyser le corps de la requête vous-même. Habituellement, vous utilisez le Apache Commons FileUpload là pour, mais si vous êtes déjà sur la nouvelle API Servlet 3.0, alors vous pouvez juste utiliser les facilités de construction à partir de HttpServletRequest#getPart() . Voir Aussi cette réponse pour un exemple concret: comment télécharger des fichiers vers le serveur en utilisant JSP / Servlet?