Archive for March, 2009

REST Service Implementation using HTTP – Cross Domain Request

Sunday, March 29th, 2009

By Phavanhna Douangboupha, 03/29/09

The three main basic ideas of a REST process are to process a client request, to response to the request, and return a result/data in XML format according to the request.

Two techniques that can be used are getting parameters from client through a URL query string and the use of HTTP methods. The first technique is easier to implement compared to the second technique. The main disadvantages of the first technique include the size of the URL string, the maximum length of the URL string consisting of query parameters, and a possible negative side effect. The first limitation, the size of URL string, can be overcome by using POST method instead of GET method for a client request. However, POST and GET methods should be applied according to a specific task (see the blog on Creating REST Web Service for more detail). Consequently, the HTTP methods are a better solution for REST service.

I have already talked about how to implement a REST client using a URL query string from my previous post, now I will talk about how I implement a REST service for the cross server client request using HTTP methods.

For this exercise, a database server, a web host server and a web client server are assigned in different machines and hosted by different domains. The database server is hosted at STREAMER. The web host server is hosted by CHW domain and finally the demonstrated web client request comes from GIBSON domain (Figure 1 shows system architect for the REST cross domain service). STREAMER is a house to MySQL database which is hosted in a different domain from the web server.

System architect for REST cross domain service
System architect for REST cross domain service

Figure 1: System architect for REST cross domain service

GIBSON is used as a demonstration client to request data from another domain (CHW). The four main files implemented here are a normal HTML file (index.html), a JavaScript file (client_local.js), and two php using cURL libraries files (getclient_chw.php and postclient_chw.php). The Javascript file is used to implement Ajax to send a request and to receive responded data sent back by a server asynchronously. The data is displayed on the HTML file. The JavaScript file uses HTTP request object to send a request to either getclient_chw.php (”How Many Users?” in the database) or postclient_chw.php (”Add New User” to the database). getclient_chw.php and postclient_chw.php use cURL libraries to set up a HTTP request where getclient_chw.php uses the GET method to request to get data from a server and postclient_chw.php uses the POST method to request to post data to a server (please see table 1 for the correspondent HTTP methods to the database query). Both of the files make a request to process data with the web server on CHW. The client side has no relation to the database server on STREAMER and it only sends a HTTP request which will later be checked by the web server.

Use Gibson to act as a client to make REST request​ (Figure 2) - http://people.rit.edu/~pxd8840/restclient/index.html . As you click one of the two buttons – “How Many Users?” (HTTP GET) and “Add New User” (HTTP POST), you will see that the displayed results are updated asynchronously. These are done via Ajax using REST service to perform a cross-domain request instead of the <script> tag hack solution as mentioned from my previous post.

index.html, client requests on GIBSON

index.html, client requests on GIBSON

Figure 2: index.html, client requests on GIBSON

On the web host server (CHW), there are two main files – rest_database.php and ConnectDB.php. ConnectDB.php is an Object Oriented PHP class that contains methods to connect to the database and the required methods to process or retrieve data from STREAMER database server. The rest_database.php file also contains all the logic check method that received from a client. The rest_database.php file is used to check what kind of request being made if it is a HTTP GET request or a HTTP POST request. According to the request, it retrieves data from the database. Then it creates XML responses to the client.

Table 1: HTTP method, REST action, and SQL command for a client request

HTTP Request Method REST Action SQL database command Description
GET GET SELECT Search/Request for
data (getdata)
POST POST INSERT Add/Insert new data
(postdata)

List of files

Client Side

  • index.html
  • client_local.js
  • postclient_chw.php
  • getclient_chw.php

Server Side

  • rest_database_php
  • ConnectDB.php class code on the server side contains database connection and database process methods

References:

Links to other blogs in this project

REST Client simple Implementation and Test

Sunday, March 8th, 2009

by Phavanhna Douangboupha

There are many ways to implement a REST web service client request which includes PHP, JavaScript XMLHttpRequest, C# system web HTTP web request, Java HttpClient, the command line:curl, Python, and Ruby. I am going to talk about PHP and JavaScript XMLHttpRequest techniques in this blog.

The purpose of using REST web service in this example is to enable cross domain database access and to take advantage of REST as mentioned in my previous blog about REST. Wikipedia has a good explaination about the technology.

There are three main portions in my small test system. First, it is a database server (data tier). The data tier is the MySQL database created on a server. Second, it is a logic tier that contains logical decision and evaluation functions between a client and the database server. At this logic tier, there are two separate files – a client side file and a server side file. The client side consists of an implementation method for a request made to the server. On the other hand, the server side contains implementation of logical decisions and evaluations. It handles all logic checks, retrieving data from the database and sending back response to a client (Figure 1 shows the flowchart for the server side logic tier). In this case, “getdata” type represents the retrieval request and the “putdata” represents the insert data operation request from a client.

The client side requests are created for both on the same domain with the server and a client request from a cross domain.

Finally, it is a very simple presentation layer to display results of the request.

Logic flow for the server side logic tier (rest_database.php)
Logic flow for the server side logic tier (rest_database.php)

Figure 1: Flowchart for the server side logic tier

A request response in this test is in the form of XML format. Two main responses are the error notification response and the data or status response. While, the error XML response is used to indicate that there is something wrong with the request or the request is not allowed. The data or status response either contains requested data to send back or status message of the request operation performed by the server.

JavaScript:XMLHttpRequest

In this test XMLHttpRequest is used to make a request for data from the database and to insert new data to the database from a client. The client is located on the same domain with the server. First a method is set up to initiate either retrieval data request or insert data request. The rest is simply a standard XMLHttpRequest with the requested parameter passing.

client_js

Figure 2: same domain JavaScript XMLHttpRequest technique

JavaScript XMLHttpRequest is widely used and it has many advantages. One includes the idea of Ajax. However, this method only works if the client and the server are both located on the same domain. How about if a client request is made from a cross domain, then this technique will not work. A well known solution to this problem is to use a cross-domain request called <script> tag hack. In brief, the way this technique works is that the data is encoded as JavaScript objects in the file instead of being located inside a function. The file is seen as a JavaScript file from a domain instead of a data request. This way, the objects will be parsed and immediately executed. I am not going to implement the method in this test; since, there is another easier and cleaner way to do it; that is the use of PHP cURL extension.

PHP cURL extension

One of the PHP methods to make a REST request is using cURL extension. I use this technique to make a data request for cross domain web service for my database; Prof. Jeffrey Sonstein has a more complete picture of RESTful API example and I use his example as a reference for my solution.

It is pretty simple to implement cURL for a cross domain request. To implement this technique, it requires cURL extension library which can be downloaded from http://curl.haxx.se/. In addition, PHP server side is required to have cURL enable configuration. Following are the steps for implementing the PHP cURL cross domain client request. First of all, http_build_query() is used to create a query string from an array which is part of the request URI. To implement a client request using cURL, we first start by creating and initializing a cURL request by curl_init() method. Then, curl_setopt() is used to set the request. The curl_exec() method is called to make the request to a server and it returns the response from the server. Finally, curl_close() is used to close the connection of the transaction after it completes the transaction.

For this test system, to request data or to insert a new data to a database on a server located in another domain, difference query command is used – “getdata” or “putdata”. The command is checked by the server side logic tier to differentiate if the request is to retrieve data or to insert data. The logic tier handles all the operations and sends back a message after it completes executing the request.

REST client

Figure 3: A cross domain request PHP technique

Links to other blogs in this project

WIMP is Dying, Long Live WIMGi

Wednesday, March 4th, 2009

From WIMP to WIMGi

The WIMP (”Windows, Icons, Menus, Pointing-device”) formulation for human–computer interaction design has lasted a long time (it was coined by Merzouga Wilberts in 1980). The phrase has become perceived as pretty much a synonym for “desktop GUI”, but I think it is dying (or at least past it’s prime). I think the death of WIMP will be a result of two things: the spread of touch-gesture oriented handheld devices, and the emergence of practical & relatively inexpensive multi-touch screens (see especially the work of Jeff Han).

So, what is taking the place of WIMP? I think we are entering the Age of WIMGi (rhymes with “whimsy”): Windows, Icons, Menus, Gesture-interface. Why is WIMGi taking hold so strongly, and what is so different about it that we need a new acronym?

New Paradigms Require New Labels

Labels have symbolic power, and a new way of thinking about the “palmtop” and “desktop” environments requires a new label. A pointing device like the “mouse” is radically different than the gestures of the human hand-and-fingers. A mouse has one on-screen representation (the “pointer”), while fingers (plural) may require a different on-screen representation and definitely require different responses (”event handling”) from a computer.

WIMGi is a new paradigm for human computer interaction; it requires new thinking about how people will get work done, and about what operations it is possible for them to command easily. In the “palmtop” environment, WIMGi is perceived by users as “more natural”. In the “big screen” environment, WIMGi seems to require more work getting “used to it”.

Big-Screen Multi-Touch

Many people were amused to note the number of “giant multi-touch video walls” appearing on television during the 2008 Presidential election. I was interested to observe that correspondents had trouble “getting used to using it” (on the physical level), and that producers had trouble figuring out how best to use such displays (on the information-transmission level). So many shows used these devices simply “because they were sexy and new”, that a range of spoofs emerged like one segment in this “Saturday Night Live” program:

Palmtop Device Multitouch

On the other hand, even simple 2-fingered stretch/shrink gestures are “understood” almost immediately by people using “palmtop” devices. I think palmtops, laptops, and architectural-drawing-stand-like surfaces are probably the easiest venue for WIMGi to take hold within, as the scale and the gestures “just seem natural” to users. I think it will take a bit longer for big-screen WIMGi to take hold.

Just as many people had a somewhat steep learning curve when first introduced to computers with pointing devices, I think many people will have a harder time learning to use big-screen WIMGi computers than palmtop WIMGi devices. Who among us has not performed multi-finger gestures on a small scale, like on the palm of your other hand? Multi-finger/multi-hand gestures “writ large” on a wall-sized screen may take longer to learn.

What do you think of all this? Critical thinking, comments, new ideas are what I am after here. And so I repeat:

WIMP is Dying, Long Live WIMGi

“Design for Mobile 2009″ Conference

Wednesday, March 4th, 2009

Presenting There

The Design for Mobile 2009 conference will take place from 20 – 22 April, in Lawrence Kansas, and I have been invited to give a session there. My presentation will be on the W3C “Mobile Web Applications Best Practices” document which we (the Mobile Web Best Practices Working Group (BPWG)) are putting together now.

This should be an interesting conference, with a real focus on design “news you can use”: case studies, best practices, and real-world “lessons learned”. My session will probably be about 25 minutes of talk, and about 25 minutes of discussion.

I hope you can attend, it should be interesting and enjoyable.