3 ms·
REST was the answer, because why have a schema define a specific input, when instead it's a lot more fun to make the input come from one of these fun places: Pa
by coding123 6y ago
REST was the answer, because why have a schema define a specific input, when instead it's a lot more fun to make the input come from one of these fun places: Path, Query, Body (Even with a GET - because why not?), Header, AAND let's not forget the Method!
- nsonha 6y agolet's not forget the prescribed verbs that give rise to CRUD APIs
- sk5t 6y agoTo play devil's advocate: why should we have all these weird little files knocking about in /etc, when we could query and mutate everything of interest on the system instead via a Management Instrumentation API?
- nsonha 6y agowrong thread?
- sk5t 6y agoNot at all - sort of an oblique argument for the unix way / "worse is better" and reasons why JSON and the disorderly REST-ish array of techniques has come to dominate over SOAP, XML, WSDL, etc. The unix way: text files in /etc, human-readable, each kind of does its own thing, but it works. Compare to: WMI, Windows registry, complex NTFS permissions, a bit more unified but ultimately a drag to deal with; complex app servers like Websphere; CORBA; and all the WS-* stuff.
- nsonha 6y ago"worse is better" isn't really an argument is it. For earch "worse is better" decision there should be an actual argument for an upside to it, eg: Window registry is more discoverable than a gazillion of directories (arguably). REST and JSON (and WS and XML) were pushed by the web mob who wants all protocols in their stack to be text-based and hackable by inspecting the traffic or whatever. In the dotcom era, their need dictated that of the industry. I think in the next era of cloud and IoT and massive communication traffic we will see more push for more efficient binary protocols (protobuff, avro) which naturally also leads to abstracting them away completely (grpc, thrift), for ergonomics.
- sk5t 6y agoI'm not sure "worse is better" is specifically an argument, but it seems to be a decent signal for survival and even broad market success. Like, if you don't need the most compact and fastest possible serialization, isn't there some benefit in text / human-readable messages? There are lots of tools for dealing with text--searching, filtering, categorizing, and so on. It seems to me that most projects never get close to the point of real suffering due to inefficient serialization, or even due to mushy schema. Look at Javascript: a terrible language, but very broadly available, and sort of easy to pick up.
- nsonha 6y ago"most projects never get close to the point of real suffering due to inefficient serialization" Individual projects are fine and no you don't personally need efficient anything. But as an industry that serves a wide range of need (people from the 3rd world, embedded systems etc), we do have the need for things that become standards to be efficient, call that lowest common denominator. Why build efficient cars or batteries if we are currently fine with them? Why go for 5G when I can do everything just fine on 4G? Could it be because when inefficiency becomes standard it compounds? What if you can have 5G perceived speed right now if all Internet protocols were binary?
- deleted 6y ago[deleted]