1. 58
  1.  

  2. 16

    Yes, I agree. It kills me to see people say a traditional website isn’t RESTful when it is actually exactly what Fielding was trying to describe in his paper. A simple website form too I’d take offense at saying it not consumable my machines: html is also machine parseable and submittable. Kinda a pity html forms don’t let the other methods be used though instead of just get and push.

    But like imagine if everyone did it with forms. You don’t need any more separate api explorers, the standard browser does it! They could include documentation right on the page, or clients could just bypass that and submit what they know.

    So I actually made my D web thing able to do a bunch of this: it reflects over the D functions and can build HTML forms to fill them in, then process it on the receiving side. Or you can submit json for the http api people. I love it and i wish more people would explore these ideas.

    1. 7

      Yeah, I blame the brain-dead verb limitations of most browsers’ HTML form implementations for an entire generation of web developers not being able to see what HTTP is. I’ve had people as me questions about “HTTP vs RPC” which is like asking “PHP vs templating language” – bur if you don’t think of HTTP verbs as freeform space then “BrowserTP” is easy to see as just a dumb tunnel that you need to layer a second RPC on top of.

      1. 2

        It isn’t strictly the implementations’ fault, since the html spec (see html4 thing here https://www.w3.org/TR/html4/interact/forms.html#h-17.13.1) only allows the two values! And html5 https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fs-method added “dialog” rather than the other keywords. I just don’t understand why they won’t expand this.

        In my library, I did a post with hidden input method - similar to what ruby on rails supports - but it is so annoying.

        1. 2

          Well, with HTML5 the spec authors are the implementors now (even more so than before) – but also if implementations had been doing this all along as part of their “extensions” someone would surely have a spec edit by now, even before they controlled the spec completely. Every single framework out there has some crazy workaround where you send a verb as a query param or similar, but no one seems to want to fix it. Well, that’s not totally true. XHR also had this limitation for awhile but fetch does not, so yay?

          1. 3

            Yeah, that’s true. I guess they’re just more interested in the next shiny thing instead of revisiting fundamentals.

      2. 5

        You should check out htmx is an attempt to extend HTML to actually be more useful. Including allowing you to send POST, PUT, PATCH or any other HTTP method from HTML without writing custom JS.

        1. 1

          This seems like the opposite of what I want. I want <form> to accept method="PAY" or whatever else, not for non-forms to be able to do ajax.

      3. 8

        Interestingly, folks have already tried to do at least some of this, coining HATEOAS for hypertext, document-style interfaces. Unfortunately, it’d really need a good marketing campaign to really make it stick, I reckon.

        1. 15

          I hate oas. Seriously, putting all-caps HATE as the most prominent word in your new term probably isn’t a good idea. I just don’t understand how they thought that was a good idea.

          1. 1

            Also not sure which came first, but everytime I read HATEOAS or HOTAS I have to stop and think.

        2. 7

          As I’ve got to understand some time ago, common language is just a tool to communicate ideas between individuals. Not the place where perfection needs to be attained at all costs. That’s especially hard for us programmers who normally work in a context or almost supernatural perfection.

          Sure saying “HTTP API” is technically better but if saying that we are going to build a RESTful API makes the concepts clear to the whole team (from the new intern to the snarky senior), that’s what we will use.

          As the article presents, since APIs implemented exactly as presented in the original paper (“trulu” RESTful) call themselves something else than REST, that means that there is no really confusion to begin with.

          This meand that if someone nowadays says REST API they actually mean HTTP API, that’s it.And if someone says Hydra, HyperMedia or ChockoMangoTM API then the other person might simply say “can you show me what you mean?” and move from there.

          1. 9

            saying that we are going to build a RESTful API makes the concepts clear to the whole team

            I feel like it doesn’t. Most people just think of HTTP methods bolted on to any kind of API. If you say HTTP API, and maybe clarify by saying “yknow, an API designed to respond to HTTP messages”, it would be considerably clearer since there’ll be no conflict between people’s varying understandings of REST.

            1. 7

              Right, exactly. If someone says a “REST API” I don’t know if they actually mean REST as originally defined or if they’re just using it to mean ‘any API that uses HTTP as a transport’.

              1. 9

                I made this mistake once. I was asked to design a REST API, and so I did. Turns out they wanted RPC over http.

                1. 2

                  Turns out they wanted RPC over http.

                  There are a ton of folks who seem to think that REST == JSON-over-HTTP, and honestly don’t understand why RPC with JSON-over-HTTP isn’t RESTful.

                  1. 2

                    LOL that made me dribble my drink i’m so sorry

                  2. 2

                    Definitely in the minority there though.

                    Not to say that you are wrong but you are underestimating how many people actually think like that, at least from my own experience. This is supported even further by the fact that this post was even made in the first place.

              2. 6

                I’ve been calling APIs over HTTP that don’t actually follow the principles of REST “RESTless” APIs (in contrast to “RESTful”).

                1. 5

                  The key thing about REST is it’s sole point is to be what you want if you want to maximally decouple client and server, because the clients and the server do not belong to the same organizational heirarchy.

                  It’s what you want if you need anarchic scalability.

                  When you can neither compel nor prevent one or a million clients attempting to access your service. When you can neither compel nor prevent the client upgrading their browser, nor can the clients compel or prevent the service from changing.

                  And all this exists in a realm where something potential better exists but one click away…

                  …thus you cannot compel the client to Read The Fine Manual… but rather allow her to discover the services as she needs to.

                  If this isn’t the realm you’re operating in… you don’t need REST.

                  If it is, you need it all.

                  Conversely, it you don’t have it all… the “something one better one click away” sneaks in every time you piss off a client.

                  1. 3

                    The description of a hypermedia API is how I imagine language servers should work. Are there any experienced LSP devs who’d like to weigh in on that?

                    1. 1

                      What are some examples of REST APIs where the client isn’t some kind of user agent? What I can’t visualise is a situation where a programmer is able to develop against an API where the data layout and actions aren’t available until the queries are complete. And if there’s a schema available beforehand to make this possible, what’s the use of self-descriptive messages and hypermedia controls?

                      1. 1

                        This was a very thoughtful and well written post. With Kieran’s permission, we recorded it as an audio episode on Blog Cast in case you want to listen to it read out, while on the move -> https://anchor.fm/blog-cast/episodes/Ep3-Should-we-rebrand-REST-e12g3bi