Posts Tagged ‘webserver’

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

Tags: , , , , , ,
Posted in Best Practices, Design, Mobile Devices, Physical Design, Web Apps, development | No Comments »

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

Tags: , , ,
Posted in Design, development | No Comments »

Creating REST Web Service

Tuesday, December 9th, 2008

by Phavanhna Douangboupha

Representational State Transfer (REST) is a web service that offers many advantages compared to Simple Object Access Protocol (SOAP) web service. REST can be a solution to mobile device web limitations. Amazon, EBay, and Yahoo are the examples of REST web services. REST service architect includes XML, HTTP, URI, and MIME type.

The first thing to consider when creating a REST is URI. Unlike URL, URI is suitable for REST since it points to a resource of a web service and hence does not change over time. Richards (2006) suggests a structure of URI for a web service.

A web service returns data in the form of XML format as defined by the service implementer (Richards, 2006). Therefore, different REST web services can have different XML format and there is no particular standard. MIME must be in the type of text/xml for XML (Content-type: text/xml).

HTTP methods that are commonly used for REST are GET, HEAD, POST, PUT, and DELETE (Create, Retrieve, Update, and Delete). Richards (2006) suggests to use GET and POST methods differently according to each functionality. He states that GET should only be used for retrieving a resource representation. In contrast, POST can be used for other operations rather than the resource retrieval including resource creation, medication, addition, and deletion. For security purposes, as a result of performing GET request, according to Gregorio (2004) and Richards (2006), there should not be any side-effects that users unaware of and therefore the implementation of GET method should be safe and idempotent. The idempotent method is the method that provides the same result every time a service is requested.

Apart from URI, data format and methods, we also have to consider the other types of web service status codes (Gregorio, 2004) – 2xx for success, 3xx for redirection, and 4xx for errors.

The next blog is going to address how REST will be used in the resource pooling and prediction project using handheld devices.

References

Gregorio, J. (2004, December 1). How to create a REST protocol. Retrieved December 8, 2008

Richards, R. (2006). Pro PHP XML and Web Services. New York, USA: Apress . Retrieved December 8, 2008, from Books24×7 database: http://library.books24×7.com.ezproxy.rit.edu/

Singh, M. P., & Huhns, M. N. (2005). Service-Oriented Computing: Semantics, Processes, Agents. England: John Wiley & Sons. Retrieved December 8, 2008, from Books24×7 database: http://library.books24×7.com.ezproxy.rit.edu/

Links to other blogs in this project

Tags: , , , , , ,
Posted in Best Practices, Mobile Devices, development, webs | 1 Comment »

Getting Work Done: Pesce's iServe Example

Sunday, August 3rd, 2008

Mark Pesce recently posted a new blog entry about why he has a Webserver on his iPhone. He calls it iServe, and it is a great example of an elegant solution to a real-world need to get things done.

Just as my answer to the "Why put a webserver on your iPhone?" question was focused on my context and perception, so his answer involves his context and perception. His context includes a need to read documents conveniently, and his perception is that he has a general-purpose computing device in his pocket.

Elegant solutions using existing technology are impressive to me.

Tags: , , , , , , ,
Posted in Logical Design, Mobile Devices, development, webs | No Comments »

A Webserver on Your iPhone? But Why?

Thursday, July 24th, 2008

Context

I have a few confessions to make: I have a first-generation iPhone named Tinkerbell, I am a hacker of hardware and software systems, I am a bit of a Twitter Whore, and I prefer to follow Esther Dyson’s aphorism to “always make new mistakes”. Context can be useful. As a matter of fact, in this story perception and context are pretty much everything.

Meeting Tinkerbell

The first night iPhones came up for sale in the US, I was across the border at a party in Toronto. I slipped into a side room, found an unsecured wireless network to work through, and banged on Apple in my Web browser until I could get a connection and place my order.

My little box arrived a few weeks later, just two hours before I was due to fly to the West Coast for the Oregon Country Fair. There was barely time to name it tinkerbell, get it synced, and hop in the cab for the airport. I figured out how to use tinkerbell during the flight West, and fell in love pretty much immediately.

I have never owned a cellular device before. I had played with cellphones before, but I had been waiting for a real “convergence device” to show up for a decade or more. I had used a Palm for years, but I did not find it satisfying. My fantasies in the 90’s were that a “JavaphoneOS” would succeed, but the fragmentation of CLDC destroyed that dream pretty fast.

From what I could tell ahead of release time, the iPhone looked like it was going to be “close enough” to being that “real convergence device” I had dreamed of for so long. I knew I had to try it out, and I think it turned out I was probably right.

Hacker Away

I was one of those kids who got in trouble all the time for taking things apart. As I got older, I got better at putting them back together. Sometimes these things worked again after reassembly, and sometimes they did not.

I have a vivid memory of when I started turning into a hacker. I was a small child, I was sitting on some throw-rug in the middle of what seemed like a gigantic floor, and my Mom gave me an old “broken” wind-up alarm clock to play with while she did something else.

I took that clock apart, I played with the pieces, and then I put it back together again. I had at least one part left over but, being a small child and still in touch with magic, I wound it up anyway. Despite the extra parts, it still worked. I was delighted and I was engaged. I took that poor alarm clock apart again, and I put it back together and took it apart over and over that day. I was trying to see what parts I could hold back and have it still work. I had become a hacker.

On some levels, I am still that little kid on the rug disassembling old alarm clocks.

Just an Old Twitter Whore

I am fascinated with Twitter and similar services. The interpenetrating webs of social affiliation represented by lists of “followers” and “following”, the spreading activation of memes and neologisms and humor, these things are irresistible to someone like me.

So I tweet. I comment on what I am doing or thinking about at the moment, I ask the twitterverse questions, I listen to what other people I respect are doing and saying. I connect, therefore I tweet.

Learning from Others

Like most other folks, when iPhoneOS version 2 came out I installed it as soon as I could get Apple’s servers to cooperate. I had jailbroken the iPhoneOS version 1.x multiple times before, and I knew that version 2 would kill that off and all the neat apps I had installed that way. I was willing to accept this as a temporary setback, a tactical withdrawal, because I know that Apple can never win that tug-of-war in the long run.

When the first public jailbreak toolkit was released (PwnageTool) the other night, I learned where to get it from the tweetstream of a friend (@mpesce) and began to walk through the steps to free my little tinkerbell from the walled garden of AppleBlessedness.

As I plodded methodically through the steps to hack my iPhone Yet Again for the new OS, I tweeted about each step of my experience. I knew that only a few others had accomplished this yet, and wanted to give people a chance to learn from my mistakes by documenting my work in my public tweetstream.

A day or two later, I finally gave up on waiting for the re-porting of Apache. I prefer Apache, but I was willing to go with any old httpd I could get up and running “for the moment”. Mark Pesce was tweeting about getting a simple Python webserver running, so I tried it out. I was unsatisfied, so I installed the lighttpd and began looking for and not finding my notes from trying lighttpd out last year.

I wanted to configure lighttpd properly, and I knew Pesce had already done the work of re-learning what went where, so I tweeted him. He helped me figure things out again, so I posted his iPhone lighttpd installation & configuration instructions on one of my servers (along with some minor process annotations by yours truly).

Perception

Of course, I tweeted about the experience installing & configuring lighttpd as I went along. And soon enough I received a personal tweet:

deleted: @jeffsonstein why in god’s name would you actually want to run a webserver on your iPhone?!

The problem of course is one of perception: to @deleted the iPhone is a cellphone, but to me tinkerbell is a handheld mobile device. And therein lies the difference. My life-context leads me to see the device one way, and theirs leads them to see it another way.

It is a Breath Mint. No, It is a Candy Mint

I think about tinkerbell in two ways: as a mobile handheld computer, and as a filesystem. My iPhone happens to have voice communications capabilities, but I still perceive it as that “convergence device” I dreamed of so long ago. tinkerbell is only incidentally a voice communications device to me, while it is probably perceived primarily as a telephone by that questioner.

I think this may turn out to be one of those “Great Divides” of perception. I say this not because of one person’s question, but because I have heard similar questions in places like the Oxford Mobile Forum for a couple of years now. There are people who look at tinkerbell and see a “smart-phone”, and there are people who see a mobile device with voice capabilities.

To me, tinkerbell is an eminently hackable, Unix-based, handheld, mobile convergence device with a filesystem. That is why I want to install a webserver and ssh and so on, and that is why I have jailbroken it anew with each OS release for about the past year.

When I go into a meeting or give a presentation, I want to be able to serve data and files to others on an ad hoc basis, in a controlled fashion, and from the filesystem on my handheld device. In that context, tinkerbell is a handheld platform for services.

When I am on the road, I want to be able to work on other machines securely from my handheld device. In that context, tinkerbell is a handheld workstation.

When I am called or call out, when I listen to music or create a voice note or record video I want to be able to use the media capabilities of my handheld device. In that context, tinkerbell is a handheld media platform.

Context & Perception

Much of innovation on the internetworks has come about because of perception and context. There is no end-to-end socket connection when you establish a TCP-over-IP socket, there is just a context in which we can choose to perceive things as though there were. There is no end-to-end cellular connection when you are talking and moving around from one tower-catchment-area to another, there is just a context in which we can choose to perceive things as though there were.

And there is no telephone here. To me, in the context of my life experiences and with my warped perceptions, to me there is just a handheld connected mobile computing device with media capabilities. And because that is how I perceive tinkerbell, that is why I want a webserver and an sshd and several programming languages on my iPhone.

I want a webserver on my iPhone because of how I perceive it. Those who cannot see beyond the iPhone’s voice capabilities, those who cannot see the computer for the smartphone, these are people who may find the next few years to be a bit confusing and rather disconcerting.

Remember, the “developed” world is pretty much a saturated market as far as cellular contracts go. The real subscriber/user growth over the next 5-10 years will be in the developing world. And just as it is getting hard to find anyone who manufactures mobile devices without at least simple cameras these days, so I assure you it will get increasingly difficult to find “dumb phones” over the next 5 to 10 years.

As handheld connected mobile computing devices with media capabilities become the norm in the “developed” world, these same capabilities will trickle down to devices going to the “developing” world. As the real centers of innovation in things like SMS and other cellular-based communications services have moved to India & Africa lately, so it seems likely that these places will become centers of innovation in palmtop information & communications technology uses. I have taught a lot of kids from these places at RIT over the past 8 ½ years, and you better believe they are just as smart and just as tech-savvy as kids in “the West”. And let me tell you, people in the “developing” world have a great deal of economic incentive to be innovators.

I want a webserver on my iPhone because I can use it now, and because I want to start figuring out some of what will happen next in the hyperconnectivity revolution.

Tags: , , , , , , , , , , , , , , , ,
Posted in Mobile Devices | 10 Comments »