5 ms·
HTTP might now be used for other things but right from the beginning (check the RFCs) HTTP stood for "Hypertext Transfer Protocol", the RFC was written by Berne
by drpixie 4y ago
HTTP might now be used for other things but right from the beginning (check the RFCs) HTTP stood for "Hypertext Transfer Protocol", the RFC was written by Berners-Lee. HTTP and HTML did come together, and from the same person.
- josephg 4y agoSo? They aren’t bundled together as the article says they are. Even on the web HTTP is used for all sorts of other content types, from images to CSS, loading javascript, JSON RPC calls, websocket connections, server sent events and so on. Outside of the web? DoH, JSON RPC, git over https, npm, video games, elasticsearch queries, … the list goes on for a long time. A very small percent of http requests transmit html. Claiming http “bundles” html is like saying XmlHttpRequest is bundled with xml, or shortening javascript to Java. It’s a strong signal that you don’t know what you’re talking about.
- 0x445442 4y agoThe HTTP verbs don’t support RPC unless you violate their specified operations. Add DO to GET, PUT, POST, PATCH and DELETE along with expanded response codes and I’m good.
- remram 4y agoWhy not use POST?
- cryptonector 4y agoYou can add verbs.
- toast0 4y agoAll those verbs are just constants that provide some behavior. POST is the constant that means I'm going to probably send you a body and probably nobody is going to try to add caching, which is usually what you want from an RPC. You can just #define DO POST, and you're set.
- cryptonector 4y agoAnd POST can come with a response body. And it can either create a new entity or not. It's what you want for an RPC, yes. That's why SOAP used it. Of course, it's not "RESTful", but hey.
- remram 4y agoRPC usually means stateful client so REST goes out the window.
- cryptonector 4y agoBrowser clients of RESTful APIs can be stateless in a very stateful way because the DOM and JS allows the client to keep state. The statelessness of HTTP is supposed to be about the HTTP layer itself, not the application, and this is true as much about the client as about the server. Consider a database application where the client is a browser and the server is just something like PostgREST, and then you see that the client stores state impliedly in the DOM (what rows it's displaying, which affects what the user might do next) and that the server keeps state in the database even though PostgREST itself is stateless. The whole thing is RESTful (because REST is in the name of PostgREST, duh; just kidding, it really is RESTful as designed). I think this RPC-means-stateful / REST-means-stateless dichotomy is just not quite right, and it leads to thinking like that in TFA. All RESTful really means is that you use appropriate HTTP verbs for the actions you're doing (especially HEAD and GET for reading so you can cache where caching makes sense), use HTTP status codes as much as possible, and give entities URIs (possibly derived on the fly) -- that's really it. If you have an RPC called `CreateWidgetyThing()` you can just as well have a POST to `/widgety-things` to create them -- it really is that simple.
- deleted 4y ago[deleted]