Book Image

Echo Quick Start Guide

By : Ben Huson
Book Image

Echo Quick Start Guide

By: Ben Huson

Overview of this book

Echo is a leading framework for creating web applications with the Go language.  This book will show you how to develop scalable real-world web apps, RESTful services, and backend systems with Echo.  After a thorough understanding of the basics, you'll be introduced to all the concepts for a building real-world web system with Echo. You will start with the the Go HTTP standard library, and setting up your work environment. You will move on to Echo handlers, group routing, data binding, and middleware processing. After that, you will learn how to test your Go application and use templates.  By the end of this book you will be able to build your very own high performance apps using Echo. A Quick Start Guide is a focussed, shorter title which provides a faster paced introduction to a technology. They are for people who don’t need all the detail at this point in their learning curve. The presentation has been streamlined to concentrate on the things you really need to know, rather than everything.
Table of Contents (10 chapters)

HTTP basics

Two of the most critical structures within web application development are requests and responses. As with most other programs, a web application needs to take inputs, and produce outputs. As HTTP is a stateless protocol, each request made will result in a response message back to the caller. For a web application, the input comes in the form of an HTTP request, and the output as an HTTP response. The net/http package contains data structures that completely model the HTTP protocol message types, which are used by most of the many web frameworks built with Go. In the following diagram, you can see the HTTP request and response protocol data structures:

HTTP request

A request, as defined by RFC-7230 Section 3, is a text-based message, which includes the following required information at a minimum:

  • Request method (RFC-7231 4.3; RFC-5789 2): The method is the action the client would like to perform on the resource. Enumerated HTTP methods are a finite list of verbs, and are outlined in the preceding two RFCs. The Go net/http package contains a list of constants for referencing the various methods, as can be seen in the documentation: https://golang.org/pkg/net/http/#pkg-constants.
  • Request target (RFC-7230 5.3): The request target, derived from the Uniform Resource Identifier (URI), identifies the resource to which it applies the request on the server. This target, which is based on the specification, can consist of multiple parts, including a host portion, path portion, query portion, and fragment portion. The Go net/url package contains logic for parsing a Unified Resource Locator (URL), as can be seen in the documentation: https://golang.org/pkg/net/url/.

  • Request HTTP version (RFC-7230 2.6): The HTTP version is the textual representation of the highest minor version within the major version of the protocol that the client is able to support. Within the Go net/http web server, this version information is populated in the request type.

The following is an example of the plain text HTTP request message which will GET the resource /file.txt from the web server, from which the client would like to navigate to the HTTP/1.1 protocol:

   GET /file.txt HTTP/1.1

The first line in an HTTP message is known as the start-line of the HTTP message. If the message is a request type message, this line is more clearly known as the request-line of the message. As you can see in the Go documentation for the request type, the first five attributes of the http.Request type encompass the data from the start-line of the request: https://golang.org/pkg/net/http/#Request.

Additionally, and optionally, the request can contain the following data and metadata if applicable within the structure of the HTTP message:

  • Request header fields (RFC-7230 3.2): Request header fields, known as just headers, are key/value pairs of metadata associated with either of the HTTP message types, request or response. This metadata is used to further describe attributes of the request, such as the length of the content body, or authentication credentials. The key/value pairs are separated by a : character, and are enumerated directly after the start-line of the message, one line per pair. There is a helpful list of registered headers that are commonly in use, which can provide guidance on request and response metadata. These registered headers are defined here: http://www.iana.org/assignments/message-headers. Within the http.Request type, there is a Header attribute which is a key to value mapping.
  • Message body (RFC-7230 3.3): The message body is the payload of the request or response in the HTTP message protocol. The client and server are signaled the fact that the message body is present by the existence of the Content-Length or Transfer-Encoding headers. The Go web server implementation takes care of these headers automatically when a response is written to the response writer. The message body on a request is accessible from the Body attribute on the Request type in the net/http package. Of particular note here is that the Body is an implementation of the io.ReadCloser interface, which contains two methods: Read and Close.

The following is a more complete HTTP request message:

   POST /file.txt HTTP/1.1
        Host: localhost
        Accept: */*
        Content-Length: 8
        Content-Type: application/x-www-form-urlencoded

        hi=there

In the preceding example, the request dictates that we want to use the POST method on the `/file.txt` target resource. Our request headers specify that we are attempting to contact a particular host which is localhost, and are willing to accept any type of response content. Since we have a request body that is URL encoded, we need a Content-Type header specifying the content type as well as the length of the request body in bytes. Finally, our request body, hi=there, is submitted as the message body of the HTTP request message.

HTTP response

Very similar to the request structure, responses also contain a start-line that is designated as the response status-line. The response may include a message body and header fields, just as the request message is capable of doing. The following data is included within the response line:

  • HTTP-Version (RFC-7230 2.6): Similar to the request HTTP-Version field in the request-line, the HTTP-Version is the protocol major and minor version in which the server is responding.

  • Status-Code (RFC-7231 6): The response status-code is a three-digit integer code that explains the response of the server. There are five different classes of status codes, namely informational (1xx), successful (2xx), redirection (3xx), client Error (4xx) and server error (5xx).

  • Reason-Phrase: The reason-phrase of the response status-line should be ignored by the client, as it is a textual explanation concerning the status of the request.

Within Go, there is an http.Response type which contains all of the previously enumerated elements within the status-line as well as a response header structure and a message body. Typically, if you are developing a web application in Go, you will generally only interface with the response type through the http.ResponseWriter type defined (https://golang.org/pkg/net/http/#ResponseWriter), which is an interface. This interface allows the developer to populate the message header fields with the Header method, and write the status-line in the message with the WriteHeader method. If the response requires a message body in the response message, the http.ResponseWriter interface has a Write method which will send the raw data as the response message body.

When looking at web application frameworks, it is important to keep in mind the bare essentials of the protocol. The HTTP protocol is a very simple text-based protocol, consisting of request and response messages that were designed to be stateless. However, some very interesting and complex systems and services have been built on top of this simple protocol. When we talk about web frameworks and Echo, we need to keep in mind how the features will affect our application, which in the end is a simple text-based protocol.