In the previous post, we talked about a browser plugin or a provider specific dedicated app for trying out REST APIs. However, they are either browser tied or API service provider tied. In

this post we talk about the system requirements for a Fiddler mobile app. We specifically target the IOS SDK as an example.

When I develop the application for a Fiddler UI on iPhone, the following are the requirements from IOS SDK:

1) single user for single device - This means that only the current user has the ability to capture traffic. The features are tied to the device and not the user. There is no login for the

application. Moreover, the application is a different instance on each device for the same user
2) ability to change proxy - This means that the application works with only the proxy for the local device. Ability to change proxy for the duration of the application is critical to the  traffic capture. By replacing the proxy with our own, we will be able to listen in on the traffic.

3) The notifications corresponding to switching in and out of applications by the user, so we can resume where we left off or operate in the background.

4) The ability to persist captures to disk so we can load them again. In the case of mobile device, we may not want to let the user save and reload captures since such action can take a lot of space. However, the ability to save captures for the current session internally is important.

5) The ability to persist cookies for the user so that his or her settings may be remembered.

6) The ability to cleanup persisted files and settings so that the application can start as if from a clean state. This also means install and uninstall should work correctly.

Developing Fiddler on the mobile application requires writing an http proxy that sits between the http server and http client and listens on the http traffic. An API explorer on the other hand can be a browser plugin that only works for the session that the user is on. Here we don't need to change the proxy on the client for the duration of the application but just the requests and responses.
Applications can be written native to the mobile device or available via the browser from mobile supported sites. The mobile supported sites shouldn't have client side scripting solutions as this may leak the client id and secret required for authentication.  The application makes webrequests and receives webresponses so it only keeps track of this.
Also, the web application regardless of the mobile device can have four components on the landing page. These are API browser, composer, history and response viewer.
Optionally, the application could sign in the user to the API providers site so that the user's profile and applications information could be retrieved. This is useful for pure client side scripting since we now rely on the username password credentials to access the APIs.
Signing in the user not only lets us use the clients credentials for authorization such that we don't have to use our own client id and client secret for the app but also limits access to the APIs to registered users.
Lastly, the application will require permissions to make web requests and receive web responses. This can be granted explicitly or implicitly by way of installing the application.
The applications on Mobile platforms such as Android, IPhone and Windows Phone could differ from each other only in the look and feel but the functionalities could remain the same across the devices.

Starbucks API Explorer view
This post will deviate from the earlier posts on networking. Here I want to describe the UI and implementation for trying out REST based APIs. Here I will address questions such as what should the UI look like ? Should it be server side implementation or client side implementation. Should it be implemented in a browser or should it be a mobile device application ?
For now we will refer to our implementation as an app.
Next, Let's look at a few use cases.
The most common use case for the UI is to target the REST APIs from a single provider. This means its targetting a known endpoint and port. In fact, the URI is structured in a way that users are scoped down to the most variable part towards the end of the URI. Thus the app should only ask for the resource qualifier and retain the value from the previous usage.
Another thing is that the the method such as GET or POST should be easily selected. On Mobile devices, auto complete works better than drop down but there is no preference between the two.
Also additional methods to auto populate query parameters should be made available such as to get tokens
The query string itself can be constructed with a name value parameters where the names are populated before hand. Each API supports a pre-canned set of query parameters and request body.Therefore name value parameters should be added on user wish to specify more. Initially this list could be a collapsible pane hiding the complexity of additional parameters unless the user wants more and more fields to populate. Typing on mobile devices is hard so reliance on user session and auto-complete feature could come useful.
The choice of method should additionally define the Request Header and Request Body.
The request header can also be thought of comprising name value pairs so the treatment given to query parameters can be the same for request header fields.
The choice of return type such as JSON or XML need not be specified in the Request header. These are very frequently used fields and hence they are candidates for independent controls by themselves.

Next, the Response can be rendered either as plain text, or with markups. If the JSON is being rendered, separating out the name value pairs on separate lines may be helpful. Similarly XML may have each element on a new line. Indentations can help in both cases.

Long strings are common in several fields of the above mentioned form, therefore splitting it and displaying it in a vertical format will help visually. Even for URLs, we could consider keeping endpoints and resource locator apart. The strings are difficult to scroll in the limited breadth of a portfolio styled screen. 

Having described the page for the composer of the HTTP request, it is important to note that endpoints are usable only when they are documented. Hence the Explorer view must provide a link to the corresponding documentation of each API. There could be a separate view to list the endpoints. This is helpful to browse all that is available. 

Also, when we talk about the overview of the pages seen when the user opens the application, we list these pages such as an API browser to show all endpoints, a Composer to make requests, a capture to show the requests and responses capture and to browse the responses in detail. 

An app to explore Starbucks API :

This is along the same lines as Fiddler or Facebook Graph API explorer. In fact mobile applications don't have a handy app to test REST URIs like we can do from desktop. This application can be made available on IPhone or Windows phone as well. 

DiffServ continued...

Forwarding techniques in Differentiated Services (DiffServ) model:
Expedited Forwarding (EF):
This is a technique that assigns different priorities to incoming traffic flows. The flows don't interfere with each other because there is no queuing delay. Flows are admitted based on their peak rate. The network does not let the rate fall below a limit. If the flow varies beyond expected rates, then the packets are either dropped or the flow is shaped. We will discuss traffic shaping shortly. Since the rate is reserved along the route for the packets, this forwarding technique can be thought of as a virtual circuit.
The example here is that of a virtual leased line service where the line is admitted if the sum of all lines does not exceed the link bandwidth.
Assured Forwarding (AF):
Assured Forwarding (AF) is a technique that maintains one or more bands of service such as gold, silver etc. Each service has a reservation for bandwidth and allocation for buffers. Within each class, there are three priorities that determine which packets get dropped when there is a congestion. Unlike expedited forwarding, the flow that does not conform is reclassified. It could end up in the unregulated best effort band.
AF and EF continue to be developed. Notice that it is the core routers where these forwarding takes place. For simple forwarding schemes, this is alright. For complex forwarding schemes, an entity such as a bandwidth broker is required that can manage the bandwidth across the core network. There are several ways to design such broker with stateless management of bandwidths across core routers.
But there are other problems as well. For example, the core routers may not all be DiffServ based. Besides flows may traverse networks with different forwarding behaviors. Packets may be handled differently by different routers along the path. A repository for listing the routers in the network such as we get with SNMP is required. This poses challenges to determining end to end service.

QoS continued

Differentiated services
This continues from the previous post on IntServ. DiffServ tries to address the difficulties with IntServ. For example, if the routers all keep track of the per flow reservations, then they don't scale when the number of flows is high such as in the case of high speed networks. Also, Diffserv is able to provide bands of service because the network as a whole makes the decisions. The edge routers decide what service model can be met. This simpler service description is signaled through the network with a method simpler than the RSVP. The packets are labeled with a priority stamp. With these labels, the core of the network finds it easy to forward packets instead of the per flow states that was being maintained. Therefore the network provides expedited services instead of best effort an d is an incremental improvement over the existing networks.
Moreover, the service providers can define and implement any forwarding behavior on top of this architecture. So service providers can differentiate their services. The architecture supports QoS by aggregating flows and yet allows service providers to implement per-flow Scalability and differentiated services are the two important advantages of this design.
Diffserv
The edge router performs the admission control functions such as classification, metering, marking and conditioning. Classification determines the labels based on rules. Metering checks whether the traffic can be accomodated. Marking marks packets with their labels. Conditioning regulates the traffic even discarding if forwarding is not possible.
The markings are based on Type of Service in IPv4 and traffic class in IPv6.
The core routers perform only forwarding according to "Per-Hop-Behaviour"  depending only on the labels. Thus the core routers are stateless. The Per-hop-Behaviour is what service providers can dictate.

QoS Discussion continued

IntServ is an IETF standard that provides per-flow QoS. Support specific applications such as video streaming because each flow is controlled based on equations. A service model describes what the network can guarantee for the flow. An application uses an interface to describe the guarantees it needs. And the network meets the guarantees by scheduling the packets. The guarantees are established at the time the applications are admitted.
Each stream or flow can have a different QoS - for example, best effort, predictive or differentiated services, and strong guarantees on the level of service (real-time).The set of services that is supported on a specific network can be viewed as a service model. Services can be selected based on performance or cost tradeoffs. Service models can be say guaranteed service, controlled load, or best effort. Guaranteed service is the best offering where bandwidth, delay and jitter are controlled and applications can expect real time performance. Controlled load targets applications that can adapt to network conditions for short durations and can specify traffic characteristics and bandwidth. Best effort has no quality of service. Both Guaranteed service and controlled load require that applications be denied admission if their QoS cannot be met. Once admitted, the QoS is maintained.
Flows are setup by sessions. Sessions define the QoS being requested by the receiver. This is usually defined by rate r  and is called the R-spec. The traffic characteristics is defined in terms of rate r and the buffer size b and is called the T-spec. Traffic characteristics are best described by a leaky bucket. The rate and the bucket size determine the flow. RSVP is the signaling protocol that is used to pass around the R-spec and T-spec to the routers where the reservation is required.
Guaranteed service uses token bucket filter to characterize traffic and weighted fair queuing at the routers.  A bit about this in detail shortly. Routers will admit calls based on their R-spec and T-spec and based on their current resource allocated at the routers to other calls.
Now back to weighted fair queuing which is a scheduling technique. This assigns different priorities to data flows that share the same communication link. Think of the link as being broken down into a number of communication channels each having varying bit rates. The sharing adapts to the instantaneous traffic demands of the data streams that are transferred over each channel. It uses statistical techniques.  With a link data rate of R and N simultaneous data flows, the average data rate is R/N. The weights are assigned to the data flows to denote the priorities. Therefore, the data flow number i will have an average data flow rate of Rwi/ (w1 + w2 + w3 ... + wn). Notice that if the weights are fractional and they add up to one, the average rate translates to probability distribution. And one flow does not affect the others if it sends packets more than its rate. As an example of weighted fair queuing, consider the CDMA spread spectrum networking. Here the weights may be the cost for the required energy
This is different from fixed sharing of links either via time division multiplexing or frequency division multiplexing. The improvement in the link utilization is referred to as the statistical multiplexing gain.
Courtesy : Lecture notes CMU and wikipedia.