5 ms·

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.

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.