4 ms·

Honestly it feels like intercooler.js is building in functionality that should exist in HTML in the first place. For example, the unintuitive "href" tag sends a

• einrealist 10y ago
  The more important part is that HTML is for human interaction. So PUT or DELETE make no sense because the server should process user input under any circumstances and not take it as is.
  • wvenable 10y ago
    Why would the server process PUT or DELETE any differently from GET or POST. I already have single-page applications that do DELETE requests to delete items.
    • einrealist 10y ago
      I do not know your applications. But PUT and DELETE are more like file operations and unless you do these things in your applications, POST is just fine. A PUT tells the server to make the payload available as is at the given URI. And if you do a GET on the URI, you should receive the exact payload that you put there. That may also include headers you send along with the PUT request (especially the Content-Type header). That's why a PUT is also able to invalidate a cache. So PUT and POST are very different. The problem with DELETE is this part of the specification: "The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully." That's why most applications are fine with using only GET and POST.
      • rimantas 10y ago
        Never so that funny interpretation of REST(ish) architecture. That R in the name is a dead giveaway that you not necessarily will get exactly what you put there. I may put json and request xml, what are you gonna do, stab me?
        • einrealist 10y ago
          Well, if the server understands the payload, it can return it in a different representation. There is nothing wrong with that. But a GET should always return the original payload when requested with the Accept header that matches the original Content-Type of the PUT request. edit: Better is to use a PUT for different representations: PUT /foo Content-Type: application/json {"foo":""} PUT /foo Content-Type: text/xml <foo></foo>
          • wvenable 10y ago
            Seems to be no reason why GET should return the original payload. No client should even expect that as the resource could easily have been changed by another client in between requests.
            • einrealist 10y ago
              Obvious, but thats not the point.
              • wvenable 10y ago
                What is the point? GET isn't even guaranteed to return the same payload every time, without PUT. Look at this website for example. The idea that you need to PUT something that be GET in exactly the same representation makes no sense given these basic facts.
      • wvenable 10y ago
        "The client cannot be guaranteed that the operation has been carried out" You can add your own guarantees on top of this specification. So in my application, the DELETE is guaranteed to have succeed if you get a positive status code.
• carsongross 10y ago
  Yep, that's the idea. It lets you more fully implement the original REST/HATEOAS concept of the web architecture: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht... And then makes a lot of stuff that currently requires javascript (e.g. CSS transitions) accessible via plain old HTML.
• xaduha 10y ago
  Ever heard of XHTML 2.0? XForms was supposed to be a part of it and it did have support for REST stuff in the spec. Well the XForms spec itself is alive and on the path to its 2.0 version. There's a number of implementations, but it seems most of dev world has an allergy to XML, which is a pity. XSLTForms works well enough, even on mobile.
• naasking 10y ago
  GET and POST are technically all you need, ie. "get representation of operation X", and "apply operation X to these arguments". It's a simple lambda calculus. The other methods are merely optimisations to these core operations, and hence, entirely optional.
  • lomnakkus 10y ago
    That's only true if you ignore the fact that operations in HTTP have semantics attached. (Or at least that was the intent. The reality is probably that they actually don't in practice. Plus, as others in this thread point out: The semantics may not actually make any sense.)
    • naasking 10y ago
      What semantics can't be captured by only GET and POST?
      • lomnakkus 10y ago
        I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake :). EDIT: Though, honestly, I must say that I also question the value of these things. For example, HTTP error codes are notoriously ambiguous and you usually need to transmit an actual response (and sometimes are forbidden spec-wise!) with an error code. I was just assuming the position of an advocate for HTTP/REST.
        • naasking 10y ago
          > I was thinking about meta-level semantics, i.e. semantics that apply to all HTTP/REST-based systems, not just one's own special snowflake Yes, but these verbs often don't yield any meaningful results or see much use in my experience. Even so, this could easily be achieved by convention using just GET/POST. Consider the HTTP OPTIONS verb. If you invoke it with * as the request-URI, it's an operation that applies to the server as a whole rather than any specific resource. This provides the solution: HTTP already reserves one URI for a specific use, and we can do the same for all of the other verbs and eliminate them from the spec if we so desired, ie. OPTIONS /some/resource => GET /options?url=/some/resource