7 ms·

> 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

by cozuya 12y ago

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

visionscaper 12y ago
I always found this extremely odd. Does anyone have a satisfying answer as to why this is the case?
- jandrese 12y ago
  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.
  - cozuya 12y ago
    Its not a good idea for HTML to support REST?
    - olavk 12y ago
      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.
    - lmm 12y ago
      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.
      - gtramont 12y ago
        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?
        lmm 12y ago
        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.
        gtramont 12y ago
        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 https://news.ycombinator.com
        lmm 12y ago
        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 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.
    - gtramont 12y ago
      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/ 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).
  - visionscaper 12y ago
    > 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.
angersock 12y ago
That would be one in a long line of quality engineering decisions by the HTML standards committees.
- einrealist 12y ago
  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.
candu 12y ago
Many web frameworks will allow you to fake PUT, DELETE, etc. via POST requests (usually using a special "_method" parameter).
- einrealist 12y ago
  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.
  - jimktrains2 12y ago
    > 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).
    - einrealist 12y ago
      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).
einrealist 12y ago
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?
- deleted 12y ago
  [deleted]
olavk 12y ago
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.
- cozuya 12y ago
  With that logic, why do forms support GET then?
  - zaphar 12y ago
    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.
    - olavk 12y ago
      GET is the most appropriate method for many forms, eg. search interfaces. It is not just a question of backwards compatibility.
  - gnaritas 12y ago
    Because input fields aren't necessarily input, they can be query parameters as well. A GET form is a query builder.
    - djur 12y ago
      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.

by cozuya 12y ago

visionscaper 12y ago

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

jandrese 12y ago
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.
- cozuya 12y ago
  Its not a good idea for HTML to support REST?
  - olavk 12y ago
    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.
  - lmm 12y ago
    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.
    - gtramont 12y ago
      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?
      - lmm 12y ago
        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.
        gtramont 12y ago
        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 https://news.ycombinator.com
        lmm 12y ago
        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 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.
  - gtramont 12y ago
    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/ 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).
- visionscaper 12y ago
  > 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.

angersock 12y ago

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

einrealist 12y ago
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.

candu 12y ago

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

einrealist 12y ago
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.
- jimktrains2 12y ago
  > 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).
  - einrealist 12y ago
    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).

einrealist 12y ago

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?

deleted 12y ago
[deleted]

olavk 12y ago

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.

cozuya 12y ago
With that logic, why do forms support GET then?
- zaphar 12y ago
  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.
  - olavk 12y ago
    GET is the most appropriate method for many forms, eg. search interfaces. It is not just a question of backwards compatibility.
- gnaritas 12y ago
  Because input fields aren't necessarily input, they can be query parameters as well. A GET form is a query builder.
  - djur 12y ago
    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.