Most mashups rely on some type of API that's freely provided by a public web site. ProgrammableWeb tracks thousands of these resources across dozens of categories. Generally, these interfaces are SOAP or REST-based, but they may also work in cooperation with other open formats like RSS or Atom. In an enterprise setting, mashups have a more diverse set of protocols to potentially leverage including JDBC/ADO.NET (databases), SMTP/IMAP (email), and SNMP (network monitoring). Unless you are building a data mashup, one of the participants API's is usually focused on visually representing the data. It could be the classic Google Maps API, or perhaps some type of charting (Google Charts is a great resource).
We typically expect a mashup to involve multiple APIs. Otherwise, what's the value-add? 1+0=1, right? Actually, there is a special case where we can mashup a resource against itself to provide interesting solutions. This single system doesn’t need to expose an API, and it often handles its own presentation. These types of mashups rely on a feature (or "Core Ability" in the parlance of Mashup Patterns) known as Clipping.
This type of mashup is an off-shoot of traditional "portal clipping" products. Most portal vendors (IBM, Oracle, JBoss) have historically offered basic clipping capabilities. These non-mashup Clipping tools are aimed at creating JSR-168 compatible portlets. JSR-168 is a specification created under the Java Community Process (JCP) to provide a standard model for portlet development and deployment. These portlets are designed to run within an overarching portlet container.
While some portlet-centric products like the open-source portletbridge offer rudimentary abilities to change CSS rules and apply XSL transforms, mashup products that offer Clipping as either a server-side feature (Kapow, Convertigo) or on the client (MIT’s Chickenfoot Firefox plugin provides comparable features through scripting) take the technology to a new level. Imagine, for example, being able to republish a web page’s UI with your own custom enhancements as a standalone product.
For example, consider this very simple internal corporate phonebook:
Without access to the source code, a Clipping mashup allows you to inject the HTML for an iFrame whose src attribute is a servlet that receives the employee name harvested from another part of the page. The servlet spits out the employee’s picture from a different resource (maybe pulls it in from Flickr or LinkedIn). Your Clipping can also add links to an internal Skills database, or list what Change Requests they have pending. This is the basis for the Usability Enhancer pattern.
I should also mention that like their portal-clipping relatives, most mashups can expose JSR-168 portlets, too (Portal Enabler pattern). This allows Clipping mashups to be easily integrated into corporate portals.
Of course, if the phonebook app already exposed an API, you could accomplish all of this by duplicating its interface and wiring all this up manually; but who wants to bother doing that? Whenever the original site’s look-and-feel changed it would be remediation time! A Clipping-based mashup picks up the changes automatically.
There are all kinds of productivity, risk, and reputational issues that Clipping mashups can address. One of my favorite examples is MIT’s Kangaroo, which works with Gmail. By injecting the photos of all of the people on your recipient list, you have immediate visual feedback that helps prevent embarrassing “reply-to-all” gaffes.