4 ms·

Its not a good idea for HTML to support REST?

by cozuya 12y ago

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

Its not a good idea for HTML to support REST?

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