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.
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.
No comments:
Post a Comment