APIs themselves predate modern networks and computing, but only became useful in networking around the year 2000 when REST was introduced. Since REST has been around longer than Thrift, we will discuss it first.
REST
REST, like other networking APIs, is available both on the local system and remotely. REST is designed to be:
- Scalable: RESTful applications must be scalable by utilizing some or all of the following concepts:
- Simplifying components: A simple component will scale better than a complex one; complex components should be broken down into multiple simpler ones
- Decentralization: This could be done by distributing processing across multiple components
- Frequency of operations: The more interactions that happen between the client and server, the more it impacts the performance of the application
- High performance: There are a few different ways in which performance can be measured:
- Network performance: The application must be adaptable to the style and size of the data it is carrying to not overburden the application
- Perceived performance: The application must minimize latency by deciding whether to compress data on the fly, create latency on the server side, or stream all of the data that may cause latency on the client side
- Modifiable/evolvable: The application must be evolvable, extensible, customizable, configurable, and reusable
- Portable: The application must be portable and return both the information and the structure
- Visible: The application must be visible to other applications
- Reliable: The application must return data in the format expected as designed within the constraints of the REST design
- Simple: By design, all REST implementations must use a uniform interface.
REST has six guiding constraints, all of which must be met for an application to be RESTful:
- Client-server: The needs of the user application are separate from the server application. The server and client may store data as they see fit but must transmit data in the requested format.
- Stateless: The application must be stateless as the server should not retain any client data from previous interactions with the same client.
- Cacheable: The data must define whether it is cacheable or not and the amount of time it can be cached.
- Layerable: You must be able to feed the application making the request from the server directly or any intermediary nodes that may have cached the required information without needing to be told so.
- Code-on-demand: The server can optionally provide code, such as compiled JavaScript or other programs, to be utilized by the client to extend the functionality of the client.
- Uniform interface: Once a developer becomes familiar with one of your APIs, they should be able to follow a similar approach for other APIs.
A uniform interface, as described by REST, must do the following:
- Identification of resources: When sending data, the data must be portable and sent in the manner the client requests, if available
- Manipulation of data by client: The client must have enough information to be able to modify or delete data
- Self-descriptive: Each message must contain the information necessary to process the message, for example, which parser (JSON/XML/so on) to utilize
- Hypermedia as the engine of the application state: A REST client after making a request to a URI should be able to utilize links provided by the server to discover the necessary information to fulfill its request
REST utilizes standard operations, such as:
- PUT: Sends data to be programmed to the REST agent, replacing or modifying the current data
- GET: Requests either a list of URIs or specific data necessary from an agent
- POST: Creates a new entry in the dataset or within a dataset
- DELETE: Deletes an entry in the dataset or within a dataset
In this book, we will focus on the SnapRoute RESTful API.
Apache Thrift
Apache Thrift (or Facebook Thrift as some refer to it) aims to provide scalable services across different programming languages. Thrift combines a generation engine for code with a software stack to create services that work effectively and efficiently between multiple programming languages, including:
- C++: A high-level programming language that is feature-full and object-oriented
- Python: A high-level general-purpose programming language
- Java: A multi-architecture programming language that allows you to run the same program on multiple different types of computers
- Ruby: An object-oriented language patterned after Perl and LISP
- JavaScript: A remotely interpreted programming language mostly utilized by web servers and websites
The goal of Thrift was to create a simple interface that could work with any programming language; to this end, the following goals are defined:
- Simple: The code should be simple, readable, and free of unnecessary dependencies
- Consistent: Language-specific code is kept in extensions, not included in the core
- Transparent: It should utilize as many commonalities between programming languages as possible
- High performance: Performance is more important than beauty; the code should be functional but not always beautiful
In comparison to REST, Thrift has an Interface Definition Language (IDL), which is programming-language-independent and is publish-subscribe instead of client-server. The publish-subscribe method is the concept where the client subscribes to the server to get the data. The client may only receive some of the data published based on filtering. Neither the client nor the server knows who each other are; it just knows the type of data to expect.
In this book, we will focus on Thrift and how it interfaces with the Facebook Open Switch System (FBOSS).
NEXT Page: SnapRoute: A RESTful API programmable routing stack
