Posts Tagged ‘client’

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 »

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 »

Shifting Paradigms, Where Context is King

Sunday, July 27th, 2008

This post originated as a series of conversations: some on Twitter, some on this blog, and some held face-to-face. On the surface, these conversations were about the issue of putting a Webserver on a handheld mobile device.

But beneath this surface lies a deeper issue: does the old client/server paradigm still apply?

Life Context

Back in the 1970s, I was a sociology undergraduate at the University of Oregon here in the States. A great prof there had finally gotten through to me the potential of statistical methods, and I wanted to see if I could apply them to some theories I had about divorce and separation patterns in the US (don’t go to sleep on us, now).

Crunching Numbers By Hand Sucks

I found out that the University was a Federal Data Repository, and that they had the entire 1970 US Census data-set stored on reel-to-reel tape (that is how I thought of it then). I also found out that the University had this thing called a “computer”, and was told that I could learn how to tell it to crunch numbers for me.

Now, you have to understand the times. I had learned to do statistics “by hand” because electronic calculators were quite expensive in those days. I knew there was no way in hell I was going to crunch the entire US Census by hand, so the idea that there was a machine slave I could tell to do the crunching for me was a delight.

Punching Holes in Cards Sucks a Little Less

I learned to punch holes in cardboard cards, how to write JCL to mount tapes, how to use an early version of SPSS, and how to write “10-statement FORTRAN” (shudder) to do the stuff SPSS wouldn’t quite do yet. I was in heaven.

Of course, I dropped card-decks into puddles (it rains a lot in Oregon), I punched the wrong holes, I mixed up card-decks into the wrong order. I was a newbie, the tech was hard to learn to use, and yet I still loved it. I did not have to work as hard at the mechanics. Instead, I could focus on the problem and the analysis, and leave most of the grunt work to the machine.

But Modems Were Wonderful

A few years later, they put in a (gasp) 300-baud modem and let people “dial up” to connect. Submitting card-decks, I had to run my jobs at midnight on the University’s IBM 360. It turned out that the data-set was too big and my operations were too complex for “normal” operations… I have never been really normal. So I generally had to wait for midnight when they would load “OS-210K”, which gave each job a whole (gasp) 210 K of “core memory” (and they really meant “core”), and I usually had to wait to get my “ABNORMAL END OF JOB” printouts until 2AM.

“Modem? What’s a modem?” I found out, and I bought my first computer and modem. The computer was an InterTec SuperBrain. It had an 8080 processor, 48k of memory, and CP/M 1.4. The modem was a big honking thing which I had to drop the telephone handset into to get work done. I used a line editor (I think it was called “ed”) to create “card images” on my 5 1/4 inch (single-sided single-density) floppy disk, and submitted jobs over the telephone from at home while in my bathrobe. This was a wonderful thing.

My computer was known as a “client”, and the 360 was known as a “server”. Servers were really big honking boxes that sat in the middle, and clients were personal workstations that sat on desktops.

That was the paradigm for a very, very long time. That paradigm is no longer viable. Period.

Shifting Paradigms

In the end, whether something is a “server” or a “client” depends upon context, and almost nothing but context. There is software on pretty much each and every machine I have or control which listens for connection requests. That part of each system is a “server”. And there is also software on all those machines which originates connection requests, and that part of each system is a “client”.

Machines themselves are rarely either clients or servers these days. Most machines can be thought of as both client and server, depending upon the context in which I am thinking/talking about that machine. Context is King, context is everything in this.

When I am on the big honking machine which acts as our Departmental Webserver and I use ssh to get somewhere else to work or I use sftp to grab files, then the context is “client”. When I am on another machine and I use http or sftp to originate requests for things from that Departmental Webserver, then the context is “server”.

Computers are no longer clients or servers

Computers act as clients in some contexts: originating connection requests. Computers act as servers in other contexts: waiting/listening for connection requests. Context is all.

This started as a series of conversations about why anyone would want to put a Webserver onto a mobile handheld computer. The answer is simple: because in some contexts I want it to listen for connection requests, and in some contexts I want it to originate requests.

jeffs

Tags: , , ,
Posted in Logical Design, paradigms, webs | 2 Comments »