1. Pick a subject

Answer the question: a mashup of what? Hint: Plotting markers on maps is probably the easiest place to start. It might just be the best delis in your neighborhood. While you could go for something more complex with muliple data sources: maps + photos + bookmarks + more, you may want to keep it simple to start.

This helps define what APIs and tools you’ll be looking at: maps, news, auctions, products, etc. Browse this site’s API Database and sort by Category to get a sense of API types. You can also browse the Mashup Listing to see which interesting applications have been built using which APIs.

2. Decide where your data is coming from

What is the source of your data? This can drive the APIs you’ll use. For example, if you want to do something with your photos on Flickr or sale items on eBay, then those vendors APIs are the likely candidates. Or, you may be inputting the data yourself such as with simple map markers. In which case your options are more open.

(For the purposes of this Guide, I won’t spend time distinguishing between a true ‘mashup’, thus 2 or more data sources, and just using an API, which may mean only 1 external source. The exact definition of mashup is vague so no need to fight semantics at the moment.)

3. Weigh your coding skills

Mashups, as of today, are mostly a programmer’s affair although there are some tools such as MapBuilder and Wayfaring that can help you create basic maps without coding.

How much of a coder are you?
Maps APIs are simplest but more sophisticated APIs, such as those for conducting financially-sensitive operations like auctions, are more complex.

How much time do you have?
Again, development speed is inversely proportional to complexity.

Do you have a server to run this on?
Simpler APIs can be used from JavaScript in a web page or take specially formated XML file as input (as shown here at Engadget). While this is indeed simple, security issues limit JavaScript’s suitability for true client-only mashups. Odds are that you will need to run your application from a web server which you manage or have access to.

What language will you use?
This is primarily driven by what programming languages you know. While your decision may also be influenced by vendor-provided toolkits, most web APIs aim to be language-agnostic so this is less of a vendor-dictacted issue than your own choice. You can use the API reference to see if an API has a language-specific toolkit (such as Flickr which has many).

Note that this whole step may arguably be Step 1, depending on your perspective.

4. Sign-up for an API

Most, but not all, API providers require you to have a developer/application ID, a user account with their service, or both. Some services give you one ID for as many applications as you write while others require you to get an ID for each application that you create. While this signup may sound complicated, and for a few services it is, most of the time this takes only a minute or two to complete. As an example, take a look at the Google Sign-up Page.

5. Start coding

For this step, the big one, rather than describe the many variations in detail, I’ll refer you to a variety of well-written and useful API-specific tutorials and introductions. You can also check the profile for any of the APIs and refer to resources from the reference section as needed.

QEDWiki is a browser-based assembly canvas used to create simple mashups. A mashup maker is an assembly environment in which the creator of a mashup uses software components (or services) made available by content providers. QEDWiki is a unique Wiki framework in that it provides both Web users and developers with a single Web application framework for hosting and developing a broad range of Web 2.0 applications. QEDWiki can be used for a wide variety of Web applications, including, but not limited to, the following:

• Web content management for a typical collection of Wiki pages
• traditional form processing for database-oriented CRUD (Create/Read/Update/Delete) applications
• document-based collaboration
• rich interactive applications that bind together disparate services
• situational applications (or mashups).

QEDWiki also provides Web application developers with a flexible and extensible framework to enable do-it-yourself (DIY) rapid prototyping. Business users can quickly prototype and build ad hoc applications without depending on software engineers. QEDWiki provides mashup enablers (programmers) with a framework for building reusable, tag-based commands. These commands (or widgets) can then be used by business users who wish to create their own Web applications.

How does it work?

QEDWiki is a lightweight mashup maker written in PHP 5 and hosted on a LAMP, WAMP, or MAMP stack. A mashup assembler will use QEDWiki to create a personalized, ad hoc Web application or mashup by assembling a collection of widgets on a page, wiring them together to define the behavior of the mashup application, and then possibly sharing the mashup with others. Mashup enablers provide QEDWiki with a collection of widgets that provide application domain- or information-specific functionality. These widgets are represented within QEDWiki as PHP scripts.

When a user renders a page within a QEDWiki workspace, the QEDWiki framework processes the widgets on the server side and then generates a DHTML page that is sent to the browser for client-side processing. The framework includes a rich AJAX-enabled MVC (Model-View-Controller) architecture so that each wiki page is a rich, interactive application for end users.

Radical simplification of Web 2.0 development

QEDWiki attempts to make use of the social and collaborative aspects of Web 2.0 by enabling the following basic actions:

• Assembly: Subject matter experts who may not be programmers can create Web applications to address just-in-time ad hoc situational needs; they can also integrate data and mark-up using widgets to create new utilities.
• Wiring: Users can bind rich content from disparate sources to create new ways to view information; they can also add behavior and relationships to disparate widgets to create a rich interactive application experience.
• Sharing: QEDWiki can be used to quickly promote a mashup for use by others and to enable multi-user collaboration on the development of a mashup.

Benefits of QEDWiki to specific types of users

The benefits associated with a QEDWiki deployment depend on the type of user:

• Mashup assemblers:
  • freeform data input with revision tracking
  • personal publishing
  • simplicity of virtual workspace construction
  • ease of situational application development
  • rich user experience.
• Content providers:
  • simple content sharing
  • detailed access control
  • quick, DIY content aggregation.
• Mashup enablers:
  • encapsulation and invocation of external services
  • size of potential development community (Web-oriented scripting languages)
  • open and sharable application source
  • viral application development and deployment
  • extensibility (plug-in and SOA models)
  • ability to import or stream external data sources
  • lower programmer skill required (reduced learning curve)
  • productivity increased through ability to quickly create applications and through live application prototyping.
• Mashup maker administrators:
  • an enabler for SaaS repository consumption
  • ease of installation
  • minimal start-up cost for infrastructure (LAMP/WAMP).

Version 1.3

Version 1.3 runs on DB2 Express C and includes improved installation, usability, and performance; a new widget explorer that allows import and export of both local and remote (client, server, and mixed) widgets; Mashup Hub integration; and improved widget development API. Because of the significantly re-designed archtecture, existing 1.1 accounts cannot be ported to Version 1.3.