Hacker News Reader

Comment by cozuya | Hacker News Reader

> Do you know why your FORM tag has an attribute called “method”? Because you’re calling a method on a web server, like a method on an object in OOP. Did you know there are other methods besides GET and POST? There’s HEAD and OPTIONS and PUT and DELETE.

Except HTML(5) forms do not support any methods other than GET and POST.

View on HN

A form is for user input and should always be "posted" through a gateway or handler on the server side. A PUT would imply that the payload is accepted as is. Also a PUT implies that a form cannot be sent twice to the same URI after the resource on the server has been created. So PUT is basically a nightmare for user interaction.

A DELETE has no payload.

OPTIONS and HEAD make no sense for a browser, because there is no information to show to the user.

So that leaves us with POST and GET. As I already stated, POST is the best form to send user data to a server. And a form with GET is just an URI builder.

Edit: Well no, that does not leave us with POST and GET, because there are also CONNECT and TRACE. But who wants to concern a user with those?

Yes, because a form is a collection of input fields, and it makes sense to POST input data to a resource. It does not make sense to say attach a collection of input fields to DELETE or OPTIONS request.

You can still use other HTTP methods from a browser (using XmlHttpRequest), just not through a form.

With that logic, why do forms support GET then?

I am of course guessing here. It's possible that I'm completely wrong since I've never been in the working group and don't really know anyone on the working group. But given what I've read publicly this seems like a likely explanation:

Because not supporting Get would break a lot of current web applications and html5 had a pretty clear goal of being mostly backwards compatible. The previous form element didn't restrict the method and GET and POST are used everywhere. Restricting GET would have caused too much confusion to be worth it.

GET is the most appropriate method for many forms, eg. search interfaces. It is not just a question of backwards compatibility.

Because input fields aren't necessarily input, they can be query parameters as well. A GET form is a query builder.

There was a time when GET forms were pretty common for search interfaces. It still works fine, but I think the sentiment against 'ugly' URLs mostly wiped them out.

Aren't GET forms still the default choice for search engines like Google? Otherwise you couldn't bookmark a search.

GET in forms is useful for query interfaces, eg. a search engine. A search should be safe, idempotent and all parameters encoded in the URL. GET is the correct choice for that.

I always found this extremely odd. Does anyone have a satisfying answer as to why this is the case?

Because nobody uses them and supporting them can cause more problems than they are worth.

The author was ranting about unused features, but not all features are good ideas. Sometimes things that look good on paper don't work so well in practice.

Its not a good idea for HTML to support REST?

HTML is designed for REST. Which is why a form does not support arbitrary HTTP methods, but only the methods which semantically makes sense for a form.

REST-the-actual-paper is a monstrosity that, thankfully, no-one actually uses. "REST" as a name for the practice of using simple JSON and using existing HTTP features (methods, status codes) rather than using HTTP as a dumb transport layer is... an ok idea, but overhyped. The supported HTTP vocabulary is very limited, and adding new verbs like PATCH is a multi-year process that's never going to be well supported by every existing piece of software. So sooner or later you're going to have to layer a more complicated (business-specific) semantics over HTTP, and have e.g. a POST that actually has semantic meaning beyond being a POST. Given that, if you just used POST for everything, and had a simple encoding of method kinds and error responses over that... would that be so bad?

Those who forget SOAP are doomed to recreate it, badly. I worry that things like JSON-schema are headed in that direction.

REST has nothing to do with JSON. How dare you saying that no-one uses while you're using the world wide web every single day?

Have you read the paper that coined the term REST? I challenge you to find a site that actually works the way that paper describes.

Absolutely. If you ever used a web browser (one that understands HTTP and HTML), clicked a link on any website, or submitted a form, you've most likely benefited from REST. Here's an example: https://news.ycombinator.com

So this site, among other things:

* Until recently, used stateful numbers for all links * Uses the same location for different resources (e.g. https://news.ycombinator.com/item) * Serves the same resources at multiple different locations, rather than redirecting you to a canonical location. * Does posting, editing and deleting via POST, not CREATE/PATCH/DELETE * Does approximately no content negotiation * Does not support non-browser clients at all, which, well I suppose you could make a perverse argument that that is HATEOAS.

In short, it behaves not at all like the system described in the REST paper.

HTML is a hypermedia format. REST is an architectural style that requires hypermedia in order to work. Hypermedia formats have factors (http://amundsen.com/hypermedia/hfactor/) that make them more suitable for some use cases and less suitable for others. HTML alone does not have idempotent updates (PUT, DELETE), but as REST allows for "Code-On-Demand", we can augment the user experience with Javascript, and it allows PUT/DELETE (with XMLHttpRequest).

> Because nobody uses them and supporting them can cause more problems than they are worth.

Can you substantiate that? Why shouldn't I be able to POST a new resource to a server and update an existing resource with PUT using Forms? Why shouldn't I be able to delete a resource using a DELETE method using a Form?

Doesn't make sense to me.

Many web frameworks will allow you to fake PUT, DELETE, etc. via POST requests (usually using a special "_method" parameter).

Which is in contradiction with the HTTP spec. Because who lets a user just add and remove resources without using a process or handler to handle the user input?

I would not use such a framework, because it did not understand HTTP and HTML specs in the first place.

> Because who lets a user just add and remove resources without using a process or handler to handle the user input?

I'm not sure what you're talking about:

1) It's user input and the user can craft a DELETE request just as well as add a _method=DELETE to the form body.

2) Most frameworks use the _method parameter as the http method, meaning when routing or when the application asks for the method so as to take specific actions. No general framework just deletes or creates stuff for you (unless you specifically set it up to, and even then you can normally add an authorization check hook).

I may have misunderstood the point you tried to make. Let me try again to make mine.

The reason HTML uses an enumeration ("get" and "post") and maps those to HTTP methods ("GET" and "POST") is that they have special meaning for user interaction. With "get" a form becomes an URI builder. With "post" the user can send data to the server. You can call it a coincidence that the values of the enumeration match the HTTP methods. The reason a "post" form is mapped to a HTTP POST is that a server should always process user inputs - even if the behavior of your application results in deleting a resource.

So yes, okay, the frameworks behave correctly, because they process user inputs. My point was to question the intent or reason behind a "_method" parameter of those frameworks. If such a framework invented the parameter because it felt limited by the HTML specification, it did not understand the specification. If it is about automating resource management, then I'm fine with that.

BTW. which frameworks do you mean? I know none (never saw that in Spring Web or WS RS implementations like Jersey).

Where we disagree is about the meaning of method in a form tag. Since it's called method and since the options are a subset of HTTPs methods, it seems natural to assume that they are related. Missing http methods does seem limiting with regards to a restful interface.

That would be one in a long line of quality engineering decisions by the HTML standards committees.

Why do you imply that the committee made a bad decision? Have you read and thought about the HTTP and the HTML specs? I guess not.

Reply on news.ycombinator.com