THe Xcode framework has MVC patterns similar to anywhere else so that different views can be navigated through controller actions. The actions can be invoked from the controls on the UI so this follows a well known pattern. Additionally the model can keep track of all object states. It can be persisted locally on the device if SQLLite provider is used. Otherwise, model can also be persisted as files. Cloud based storage for model could be possible via iCloud Service.
The controls can be dragged and dropped from the toolbox to the emulator. This is a very visual designer way of describing the page. And we can set various properties on the page as well. In addition, the same controls can be dragged to the controller to show what is associated with the actions. The Objective C framework let us use the objects directly. For example, a button can be dragged to the controller to describe what action is associated with it. The simulator to code connection is tracked with a line so it's easy to follow and to drag and drop.
In our case where we want to design a user interface to make web requests and responses, we could rely on the ASIHttpRequest library. That code can directly be included in your application and it makes GET and POST request easier than the native support. The form on our user interface can help with making the request while the response will simply be echoed out to the screen. This single page interface is sufficient for this kind of a request response view.  This doesn't mean we can't add more pages. Different pages can be added via different views and workflows to navigate between the views can be specified through the controller. The framework allows you to run the app in universal mode so that it can be used directly with both iPhone and iPad without customizing for any one. In addition, there are ways to sign and package your application so that it can be published to the app store.
As a way to test the application with full web request and response, there is a test project created with the source. This can be used to incrementally add features via test driven development. It is nevertheless important to have tests run on the code prior to publish even if this is strictly not followed. At the time of publish, while the code may not change, there may be additional changes coming in via picking out images and themes for the application. Hence, trying out the app from the app store will surely be recommended.

IPhone applications are written with XCode and IOS SDK. The apps are written with the building blocks provided by the framework. The language is Objective C. Creating a hello world application with a one page is easy because you choose the templates, pick the controls and write the associated controller logic. You can test the app in the simulator that comes with XCode.
Publishing an app is also easy using the following steps. Apps are published through the App store. You provide the app and the digital certificates. The App is then compiled and submitted to the App Store. You need the following : identity which is a unique id for an app, a distribution certificate and a private key  that is generated in the app store, a distribution provisioning profile, icons and loading screens. 

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.