Web Interface Development (SOAP,REST,gRPC)


In 1990s, TCP/IP matured to become a gold standard for networking, and people started to consider a shift to cross-platform communication. Technologies such as CORBA (Common Object Request Broker Architecture), DCOM and Java RMI were developed in order to use developer-friendly abstraction layer over core network infrastructure, to promote language-agnostic communication over client/server architecture.


In early 2000, HTTP gradually evolved to be the web standard for communication. HTTP combined with XML offered a self-descriptive, human readable, language agnostic and platform independent framework for remote communication. This combination resulted in the standardization of SOAP (Simple Object Access Protocol) and WSDL (Web Service Definition Language), which provided interoperability among various runtimes and platforms.



    <name>John Doe</name>
cout << "Name: "
       << person.getElementsByTagName("name")->item(0)->innerText()
       << endl;
  cout << "E-mail: "
       << person.getElementsByTagName("email")->item(0)->innerText()
       << endl;

Question: How to pars XML, convert XML to HTML? Is it because XML is similar to HTML that people use XML for communication?


When it comes to Web 2.0, programmable web formed the next wave to hit internet. The combination of HTTP and XML defined as SOAP standard are too restrictive for many developers, then it come JavaScript and JSON. API played a key role in Web 2.0, and HTTP + JSON became a new unofficial standard called REST. SOA was confined to large enterprise applications that requires strict schema definitions and standards, while REST was popular for contemporary developers.


With the rise of JavaScript frameworks, Node.js and document database, REST became wildly popular among web developers. Many applications started to rely on REST even for internal serialization and communication patterns. However, HTTP may not be the most optimal protocol for exchanging messages across services running in the same context, network and possibly the same machine. HTTP’s convenience comes with a huge performance trade-off. So people began to look for the most optimal communication framework for microservices.

Question: What are the drawbacks of HTTP? Why HTTP cannot scale to milions of RPCs per second? What is microservice?


Within the first year of launch, gRPC was adopted by CoreOS, Netflix, Square, and Cockroach Labs. Etcd by CoreOS, a distributed key/value store, uses gRPC for peer communication. Telecom companies such as Cisco, Juniper, and Arista are using gRPC for streaming the telemetry data and network configuration from their networking devices.

gRPC is similar to CORBA in the way that both the frameworks declare the service in a language-agnostic Interface Definition Language (IDL), and then generate language-specific bindings. Both CORBA and gRPC are designed to make the clients believe that the server is on the same machine. Clients invoke a method on the Stub, which gets transparently handled by the underlying protocol. But the similarities mostly end with this.

gRPC’s secret sauce lies in the way the serialization is handled. It is based on Protocol Buffers, an open source mechanism for serializing structured data, which is language and platform neutral. Similar to XML, Protocol Buffers are verbose and descriptive. But they are smaller, faster, and more efficient than other wire-format protocols. Any custom data type that needs to be serialized will be defined as a Protocol Buffer in gRPC.


# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
  name: "John Doe"
  email: "jdoe@example.com"
cout << "Name: " << person.name() << endl;
  cout << "E-mail: " << person.email() << endl;

When this message is encoded to the protocol buffer binary format (the text format above is just a convenient human-readable representation for debugging and editing), it would probably be 28 bytes long and take around 100-200 nanoseconds to parse. The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse.

Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:

  • are simpler
  • are 3 to 10 times smaller
  • are 20 to 100 times faster
  • are less ambiguous
  • generate data access classes that are easier to use programmatically

However, protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).

When compared to REST+JSON combination, gRPC offers better performance and security. It heavily promotes the use of SSL/TLS to authenticate the server and to encrypt all the data exchanged between the client and the server.

gRPC uses HTTP/2 to support highly performant and scalable APIs. The use of binary rather than text keeps the payload compact and efficient. HTTP/2 requests are multiplexed over a single TCP connection, allowing multiple concurrent messages to be in flight without compromising network resource usage. It uses header compression to reduce the size of requests and responses.







Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s