A few decades ago I had a epiphany while developing code for a telephone company. The code interacted with a database, telephone switches, credit card agencies, ACH and the Internet.
My initial thought was that the program should be a combination of Java Servlets and Java Applets because Java is the greatest programming language ever conceived. I disliked having a program that could initiate financial transactions called from the Internet.
I felt that the Applet code was secure, but what would happen if a hacker launched a brute force attack on the web servers?
I contemplated the situation. Each of these systems had a native API used for input/output (io) procedures. Despite the fact that Java was the greatest programming language ever conceived and that Java the most superior programming interface ever conceived, I decided that my safest bet for creating a secure program was to interface with each component of the application with the system's native interface.
The native interface for the Web is a strange structure called HTTP (HyperText Transport Protocol).
Tim Berners-Lee developed HTTP while working at CERN in 1989. Is a data structure that includes routing information and a program request.
When you click on a hyperlink in a web browser. Your web browser will created an HTTP request which it sends over the internet. A web server will receive the HTTP request and return an HTTP document back to the browser. This HTTP structure will often include hypertext pages or images.
NOTE: HTTPS is HTTP encrypted at the transport layer. From the application's perspective, it is pretty much the same as HTTP. The header simply has flags indicating that the request had been encrypted and decrypted.
My epiphany was as follows: Even though Java has the most superior programming interface ever conceived, I really should optimize my code for the native interface of each system. The native interface of of Internet is HTTP.
Several terrible thoughts followed my epiphany. The first was that despite all of the superiorness of the JAVA API, Java was not the best programming language for the internet.
Web development is largely about assembling and disassembling HTTP requests. The web is better suited for functional programming than object-oriented programming.
That meant that, despite all of the superiorness of Java, the web is better suited for plain old languages like C, or scripting languages like Python of even PHP.
Every programming language that survived the 1990s incorporated mechanism for assembling and disassembling HTTP requests. As a result most computer programs have mechanisms for interfacing with HTTP.
Notably, CURL is a program that allows hackers to generate HTTP requests at the command line.
In my last post I lamented that HIVE Developer's tutorials have built in dependencies on convoluted application frameworks. They have frameworks for JavaScript, Python and Ruby.
The frameworks contain tens of thousands of lines of code.
These extremely complex frameworks assemble relatively simple HTTP requests.
The problem is that anyone who implements a program based on the code in the tutorials will end up creating an application with dependencies on the superfluous code from the framework.
I've been picking on #HiveInvite because this is a very important semi-official site. The site was designed to let HIVE users invite new users to the platform.
The site does not work because there is an error somewhere in the complex application framework.
I contend that the complex application frameworks being pushed by the Hive Developer Tutorial inject unnecessary dependencies. Even minor changes to these frameworks cause programs like HiveInvite to crash. This causes headaches for the users and make HIVE applications difficult to support.
I contend that the better model would be for HIVE to simply accept that HTTP is the primary interface for the blockchain.
To support my argument, I will dig deeper into the tutorial.
The Recipe Section of the tutorial shows that the account creation project is a simple matter of creating an HTTP request embedded with a JSON object.
The Create Account section of the HIVE tutorial shows the workflow of creating an account involves sending one HTTP request to get a key that will authenticate the second.
The API does something really odd. It has the external application generate the API keys. Personally, I would have the back-end generate the keys and send the keys back to user. This is not really a security hole. If the front end generates the keys; a lazy programmer might decide to skip the key generation process and create accounts that have the same key. I'd have to read the back end code for HIVE to see if that was possible.
I no longer need to create an account. If I really needed to create an account, I probably would do so through LeoFinance or one of the other tribal interfaces.
I just want to point out that JavaScript, Python and Ruby APIs presented in the tutorials take something that is relatively straight forward and turns it into something that is excessively convoluted.
IMHO, the APIs presented the tutorial are superfluous. HTTP is the native API of the web. The front end APIs really don't do anything more than create HTTP requests.
I am not a hacker. I don't need an account; so, I haven't tried creating an account.
A true hacker would simply look at the API, then run scripts that randomly throws HTTP requests at the server in search of security holes.
I grabbed the picture for this post from bigstockphoto:
This is an interesting post here! I think that we can certainly appreciate that the native and most common language in the world for computers is http so adapting things to that instead of making they more complicated than they need to be is probably a good idea!
Thanks for the reply. I was worried that the post wasn't going to make sense. But you summed it up perfectly.
Every programming language on the Internet has a way to interface with HTTP. Most programmers know how to send post and get requests from the language of their choice.
I believe that if the HIVE developers decided that HTTP was the primary interface and concentrated on writing code for a given set of HTTP requests that they would end up with a system that was both easier to maintain and extend.
So, imagine some bank with half of their code written in COBOL. COBOL can send and receive HTTP requests. The financial analysts who are stuck doing everything in PL/SQL can send HTTP requests.
Beem and dhive.js still have their place. They are great for people who want to concentrate on developing full fledged HIVE based web sites.
Financial institutions that just want a quick way to integrate some crypto into their current products would prefer the HTTP route as they could integrate HIVE just by adding a few HTTP calls to their current programs.
You're stating your case without any support. It would be nice if you threw in which frameworks are added and how much space they take.