This is fairly rare, and for larger request/response pairs the overhead is minimal.
There are some examples where a request might have fit in only one packet if compactly encoded in TCP but instead require 2 with HTTP. Ethernet packets almost always have an MTU of 1500 bytes. In practice this only becomes important if it increases the number of packets. HTTP is also great in that you can easily switch to HTTPS with no major changes to have a secure, encrypted data transport layer. HTTP has an overhead for request & response headers and the text encoding of the HTTP commands. It is immensely debuggable and you can hit it with standard unix tools like curl & wget or even just read the text output with telnet. HTTP/1.1 is the human-readable text-based application-level protocol that you use when reading web pages. On textual data there usually isn't a big win from binary formats, but there may be significant savings in a big-data system that is handling large amounts of numerical data. Good binary formats tend to be much more compact and easier to parse. Most modern formats have pretty solid backward compatibility stories though forward compatibility support with some features like enumerations may be spotty. Library availability depends on the popularity of the data format and also the programming language used. In some cases, if you are transmitting specialized binary data that you don't feel maps well to JSON you might have to Base 64 encode it with a 33% space overhead.īinary format - Machine-only data format that conforms to a specification that can be hand-coded or can be a generic data format like protocol buffers. This can be partially mitigated with compression at the expense of CPU. The primary drawback is that data requires additional memory to store and uses extra space over the network since it is stored in a friendly human-readable format.
The simple format works with all programming languages.
JSON formats have excellent forwards & backward compatibility stories with easily-evolvable APIs. JSON (or similar things like YAML) - Human-readable, flexible format that is easily debuggable. These choices are theoretically independent but certain combinations are used more frequently. First, the representation of the input/output used. There are two additional choices to be made. RESTful APIs can be self-documenting and easily discoverable. RESTful systems view HTTP endpoints, that can be distributed across difference services, as resources that have an associated set of standardized verbs (GET, PUT, POST, DELETE) that can be invoked to interact with the resource. REST, short for "representational state transfer" originated from Roy Fielding's PhD dissertation. Some of the more popular (at least for the JVM) are Thrift, Spring RPC, and Finagle. It functions like a normal method call, accepting a set of parameters that are serialized over the network and a response that is serialized over the network. The idea is simple - execute some method by name on another computer. RPC is short for "remote procedure call". I'll also discuss why LinkedIn chose to build rest.li, our open-source framework for building RESTful applications. So it's time for a showdown of REST vs RPC. On balance I disagree, but as with anything there are a set of tradeoffs to consider. He then followed up with a stronger statement, that today's RPC systems were as good as or even better than REST systems.
An engineer who I respect very much recently asked in a public forum why LinkedIn chose to use a REST-based framework for building our stack instead of an RPC system.
0 kommentar(er)
