February 2011 Archives

SOAP vs REST

To understand SOAP and REST you must first understand web services. A web service is a method by which two pieces of software can communicate over a computer network, such as the Internet. SOAP and REST are two different approaches to satisfying this need. They differ in many ways such as their design philosophies, the concepts they define, the effort involved in using them and how they interact with HTTP.

SOAP, Simple Object Transfer Protocol, is built upon the design philosophy of remote procedure calls. In this way SOAP allows software to connect over a network and invoke behavior in other software. This ability solves a common problem in large-scale distributed software systems often found at large enterprises. On the other hand, REST, also known as Representational State Transfer, draws from very different design philosophies. It is based upon the concept of exchanging data. REST web services aim to exchange data as simply as possible by leveraging what is already available.

Since these two techniques differ in philosophy, they also differ in what they define and what they leave up to the implementer. Where SOAP defines a specific format for message exchange using XML, REST does not require any specific format to be used. REST does however constrain the actions performed by a service to those provided by the transfer protocol on which is operates. SOAP allows for any number of methods to be defined thereby providing more flexibility in the behaviors that clients can use.

Implementations of REST and SOAP are also very different. Despite its name, SOAP is a very complicated protocol governed by a set of formal specifications. Implementations often involve large toolkits and are assisted by other protocols like WSDL. Additionally, since behavior is being invoked from a remote system, security is a major concern. Conversely, REST is a general concept that relies mainly on other existing standards to define itself. As a result REST web services can be implemented more easily without the need for REST specific toolkits.

While theoretically a web service can be implemented on top of any data transfer protocol, web services almost always use the ubiquitous HTTP. This is the same protocol your web browser uses to load web pages. REST web service designs attempt to harmonize with HTTP by using its existing vocabulary including both the verbs of HTTP, such as get and post, and the response codes, such as 400 for a user error. This allows REST web services to leverage existing HTTP reliability and scaling technologies quite easily. SOAP, however, is more concerned with consistency regardless of the data transfer protocol used. As a result it draws very little from existing HTTP concepts. SOAP instead defines its own vocabulary, which must be interpreted in addition to HTTP for an integration to function.

In the end SOAP and REST are very different approaches to solving slightly different sets of problems. REST based web services may be easier create and integrate; but some problems, such as system wide distributed transactions, can be more straightforward to implement using behavior centric models like SOAP.

Nearby Events on Eventbrite

Welcome back!

It’s time to continue exploring the Eventbrite APIs. Today we’ll write a very simple PHP page finds events very close to a specific latitude and longitude using the event_search API.

What You Need

Something to Start From

We are not here to learn about writing forms in PHP, so to get us started here is the skeleton of an application to which we will add Eventbrite functionality.

<?php
$app_key = "exampleApiKey"; //Supply your Eventbrite App Key here.  Remember to keep your App Key secure!

if (!(isset($_GET['latitude']) && isset($_GET['longitude']))) {
    //No coordinates are set. Display a very simple form to request a latitude and longitude
    ?>

    
Latitude Longitude
<?php } else { //We have coordinates! Lets get busy. //Normally we'd validate the input here, but we'll skip that ugly stuff $latitude = $_GET['latitude']; $longitude = $_GET['longitude']; print "I will search for events near lattitude $latitude longitude $longitude.

\n"; }

Go ahead. Paste it into your editor and see how it works. On first load it will display a form with two fields: one for latitude and one for longitude. When submitted the page will print the supplied latitude and longitude values.

Constructing the Query

To fetch a list of events we must query the event_search API. All we need to do is to put together a URL that specifies our event search filters. For this tutorial we need to specify three parameters. Two of these come from our form: latitude and longitude. The third, within distance, we will hard code for the sake of this example. 1 mile seems like a reasonable within distance.

$request_url = "https://www.eventbrite.com/xml/event_search/?app_key=$app_key&latitude=$latitude&longitude=$longitude&within=1";

Executing the Request and Interpreting the Response

We can now use our favorite PHP HTTP client, cURL, to execute our freshly created API request.

After we execute the request we can parse and interpret the response. If the API request failed, we expect to see an <error> element at the root of the document. This element will contain an <error_message> element. We will display an error message if it is available.

Under normal conditions our API request will not contain an <error> element. In this case the response contains an <events> element with a single <summary> element and many <event> elements as children. We will display the total number of discovered events and list the titles of each event returned. Note that this API uses paging, so for popular areas not all event titles will be printed.

    //Next, lets hit the API with cURL
    $ch = curl_init($request_url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    $response_body = curl_exec($ch);

    //We have our result in a string. Lets parse it.
    $xml = new SimpleXMLElement($response_body);

//    var_dump($xml); //Uncomment this line to see the entire parsed response

    //Check our parsed response for problems (such as an errors element). If there's an issue, let our user know.
    if ($xml->error_message) {
        //something is up here
        $error_message = $xml->error_message;
        print "Eventbrite responded with an error: $error_message

\n"; } else { //Things are looking good. We can start by printing some of the response summary data print "I found " . $xml->summary->total_items . " nearby events. Here are the titles from the first page of results: \n"; //The bulk of our response is a list of events. Let's display each event title. print "
    \n"; foreach ($xml->event as $event) { print "
  1. " . $event->title . "
  2. \n"; } print "
\n"; } //some boilerplate clean-up stuff curl_close($ch);

The Result

Visit this PHP page and supply the latitude and longitude for a location that is likely to have some upcoming events. Try a latitude of 37.78 and a longitude of -122.4. This will search a populated part of San Francisco.

You should see something like this:

I will search for events near lattitude 37.78 longitude -122.4.

Hitting https://www.eventbrite.com/xml/event_search/?app_key=APP_KEY&latitude=37.78&longitude=-122.4&within=1 to find nearby events.

I found 369 nearby events. Here are the titles from the first page of results:

  1. Manor West
  2. Signature Series at MANOR WEST DJ Z-TRIP
  3. “Signature Series” at Manor West ~ featuring Yolanda Be Cool: “We No Speak Americano”
  4. Elite Session With STIMMING
  5. FIP Seminar at San Francisco WestEd
  6. Bridal Stylist Training & Certification
  7. Image Consultant Certification Training
  8. Learn Color Analysis Get Certified Too!
  9. MAKEOVER YOU and Get the Date, Job, Money!!
  10. City Nights Mardi Gras 2011 featuring DJ CLASS

Knock It Up a Notch

We have a list of events within a mile of our latitude and longitude. If we happen to be carrying our GPS and are simply curious about what is going on around us, this may be useful, but there is so much more that we can do with this API. Here are a few ideas for features that you may wish to add to our search tool:

All of the Code

Did some of my instructions confuse you? Would you like to skip all my wordy explanation and just hack at the code? If so, here is the complete code for this tutorial.

Enjoy!

<?php
$app_key = "exampleApiKey"; //Supply your Eventbrite App Key here.  Remember to keep your App Key secure!

if (!(isset($_GET['latitude']) && isset($_GET['longitude']))) {
    //No coordinates are set. Display a very simple form to request a latitude and longitude
    ?>

    
Latitude Longitude
<?php } else { //We have coordinates! Lets get busy. //Normally we'd validate the input here, but we'll skip that ugly stuff $latitude = $_GET['latitude']; $longitude = $_GET['longitude']; print "I will search for events near lattitude $latitude longitude $longitude.

\n"; //First, we need to construct our request URL $request_url = "https://www.eventbrite.com/xml/event_search/?app_key=$app_key&latitude=$latitude&longitude=$longitude&within=1"; print "Hitting $request_url to find nearby events.

\n”; //Next, lets hit the API with cURL $ch = curl_init($request_url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $response_body = curl_exec($ch); //We have our result in a string. Lets parse it. $xml = new SimpleXMLElement($response_body); // var_dump($xml); //Uncomment this line to see the entire parsed response //Check our parsed response for problems (such as an errors element). If there’s an issue, let our user know. if ($xml->error_message) { //something is up here $error_message = $xml->error_message; print “Eventbrite responded with an error: $error_message

\n”; } else { //Things are looking good. We can start by printing some of the response summary data print “I found ” . $xml->summary->total_items . ” nearby events. Here are the titles from the first page of results: \n”; //The bulk of our response is a list of events. Let’s display each event title. print “
    \n”; foreach ($xml->event as $event) { print “
  1. ” . $event->title . “
  2. \n”; } print “
\n”; } //some boilerplate clean-up stuff curl_close($ch); }

Getting Started With Eventbrite APIs

Hello!

It’s time for a bit of a departure from my usual blog structure. Instead of writing about a specific annoying error message and SEOing the heck out of it, I’ll be writing a short series of posts describing a new set of APIs that I’m playing with: the Eventbrite APIs.

The Eventbrite APIs are roughly RESTful. This is very good news. We can begin our exploration using off-the-shelf tools like command line cURL.

First we’ll experiment with failure and success in searching for an event, a read operation. Once we have a handle on reads, let’s create a new event.

What You Need

  • Command line cURL (You already have this if you are on OS X or Linux. Try Cygwin if you are on Windows.)
  • An Eventbrite app key
  • Your Eventbrite user key for creating data

Fail First

To clearly understand success, it’s often importnat to fail at least once. Understanding this failure makes it easier to identify success.

From the event_search reference documentation we can see that an app_key parameter is required. Let us access the API without specifying one to see what happens.

$  curl -i 'https://www.eventbrite.com/xml/event_search'
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 19 Feb 2011 09:51:43 GMT
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Vary: Accept-Encoding


        Please provide your Application Key in the URL as "?app_key=".
        Application Key Error

$ 

Did you notice anything interesting? The response body is as expected, an xml document describing our missing app_key, but check out the HTTP response headers. The status is 200 OK. You may have expected an HTTP 400 response of some kind since the request failed. We now know that the API may respond indicating success even when there is a problem. We cannot rely on the HTTP status in our application and must always parse the response body and check errors.

Success in Search

As we saw above, failing on purpose teaches us important lessons, but success is much more satisfying. Let’s add our api_key into our query URL and observe success.

$ curl -i 'https://www.eventbrite.com/xml/event_search?app_key=exampleApiKey'
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 19 Feb 2011 10:05:10 GMT
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Vary: Accept-Encoding


    
        
        
        12058066
        46957451
        10
        42114
    
    
        ... a very long list of events ...
    

$

As we hoped, there is a long list of event elements in the response body. The list of events is a bit arbitrary, since we did not specify any filters, but that is no surprise.

Try some queries with filters and observe the narrowing of the response list. Here are some URLs to get you started:

  • https://www.eventbrite.com/xml/event_search?app_key=exampleApiKey& keywords=google%20OR%20multimedia
  • https://www.eventbrite.com/xml/event_search?app_key=exampleApiKey&postal_code=94107
  • https://www.eventbrite.com/xml/event_search?app_key=exampleApiKey&date=today
  • https://www.eventbrite.com/xml/event_search?app_key=exampleApiKey&count_only=true

Creating an Event

Searching events is pretty powerful, but a proper application

$  curl -i 'https://www.eventbrite.com/xml/event_new?app_key=exampleApiKey&user_key=exampleUserKey&title=test&description=testDescription&start_date=2012-12-31%2010:00:00&end_date=2013-01-01%2002:00:00&timezone=GMT+01'
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 19 Feb 2011 10:43:46 GMT
Content-Type: application/xml
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Vary: Accept-Encoding


        1341790331
        event_new : Complete 
        (Draft)
        OK

$ 

It looks like we’ve created an event! You can see this event in your My Events page.

You have probably already figured this out, but even though we made an HTTP GET request, which is supposed to be repeatable, be careful not to repeat this query as it will create additional events.

Conclusion

In just a few short minutes, without writing a single line of code, we have learned a lot about the Eventbrite API. Taking care to look before we leap can save us countless hours down the road.

Armed with some new facts about the Eventbrite API, it’s time to fire up our favorite text editor or IDE. You guessed right, it’s time to code!