We're halfway done allowing users to add new pages to our wiki.

We've created an HTML form that browsers can retrieve using HTTP GET request.

The problem now is that when the completed form is submitted,

the browser sends a second request that we're not prepared to handle.

We need to set up our app to accept this second request and

save the form data to the server.

When we submit the form for a new page,

notice that the form fields are being encoded and added onto the URL.

That's because our form is being submitted using a GET request.

Using an HTTP GET request is fine when you're getting data from the server,

when you type in a URL or click a link, you're just getting a new page, so

your browser sends a GET request.

It's even fine to use GET requests for

simple search forms on a website, because you're still just retrieving data.

That's why browsers use GET requests by default when submitting an HTML form.

But when you're adding new data to a server that will be accessible at

a new path, you're supposed to use an HTTP POST request instead of a GET request.

There are various technical reasons for this,

which you can read more about in the teacher's notes if you want.

But there's one very visible benefit to switching to POST request right now, and

it's that form parameters are submitted in the request body

rather than encoded in the URL.

That means no long ugly URLs when we submit the form.

So let's go back into our new.erb template.

We're gonna edit the age female form to submit via POST instead.

We do this by adding a method attribute to the form element, and

we're gonna give it a value of post.

And just as GET request need a particular path on the server to retrieve,

POST request need a particular path to send their data to.

Whereas the path for GET request is specified the using the URL, the path for

POST request is specified in the form HTML.

To set that up we'll need an action attribute.

To set that up we'll need an action attribute.

Because we're creating a new wiki page.

Let's save that, reload or preview.

Fill in our form, And click Submit.

Our browser goes to the /create path.

And you can see there's no encoded form parameters in the URL.

But we also see the error, Sinatra doesn't know this ditty.

That's because we haven't set up a Sinatra route that can handle this type of

request yet.

We'll take care of that in a bit.

We can confirm or

sending a POST request now by using our browser's developer tools.

Let me go back to the new page form here.

Then I'll open developer tools.

Expand that a bit, and click on the Network tab.

Down here it says Recording network activity.

Perform a request.

So I'll resubmit the form to perform the POST request.

We can see the request down here at the bottom.

The server still failed to respond, which is why it's highlighted in red.

But you can see that the method is POST.

If we click on the request, we can view its details.

We can scroll down to Request Headers and click View Source, and

we'll see that it did indeed send a POST request for the create path.

We can also scroll down to the bottom to view the Form Data that was submitted.

There's our title field and a content field.

So now our browser is sending POST requests with the form data.

Our next step is to set up our Sinatra app to actually process that data.

We'll look at that next.