In most cases The Same Origin Policy is desirable. It helps to prevent malicious code that could potentially reveal sensitive information from being run on arbitrary website. However, the same origin policy also makes it difficult to share resources within a common root domain, or run external widgets on your site (like displaying The Project Badge within your site). There are a couple ways to circumvent The Same Origin Policy, but I focus on JSONP and the document.domain property in this post.

Ways to circumvent the Same Origin Policy

1. JSONP
2. Modifying the document.domain property
3. Creating a server side web proxy

JSONP (JSON with padding)

How it works: JSONP dynamically creates a script element in the head of your HTML document which then requests data from outside your domain. JSONP exploits a loophole in the Same Origin Policy that allows JavaScript from an external sites to be run within your site (much like how web analytic tracking works). The JSON response, when returned, is executed within your browser at which time the JavaScript can manipulate your HTML page / DOM.

An Example Using JSONP with jQuery:

Note the callback=? at the end of the URI, in jQuery this indicates a JSONP call.

Pros

• Lets us make external calls to any endpoint that supports JSONP
• Lets us make external calls from HTTP to HTTPS
• Supported by all major browsers

Cons

• A bit more complex upfront, but most server side technologies support JSONP, browsers are natively supporting JSON, and JavaScript libraries like jQuery continue to abstract away most of the complexity.

The document.domain property

How it works: the document.domain property contains the domain of the server from which the page was loaded. For example, the domain for http://adam.kahtava.com/ would be adam.kahtava.com whereas the domain for http://kahtava.com would be kahtava.com. The Same Origin Policy restricts resource access from kahtava.com to adam.kahtava.com unless we set the document.domain property to the root domain (in this case I'd want it set to kahtava.com to share resources with http://adam.kahtava.com).

An Example using the document.domain property:

Pros

• An easy way to access resources within our root domains
• Supported by all major browsers

Cons

• Prevents us from making external calls outside a root domain
• Prevents us from switching between HTTP and HTTPS
• Kind of a hack - technically, the document.domain property is supposed to be a read only property, but most browsers also provide set access

JSONP vs document.domain isn't a cut and dry comparison. JSONP lets anyone consume and share data, whereas overriding the document.domain lets you share resources within a common root domain. In simple cases where your only concern is sharing data within a single domain (exclusively on HTTP or exclusively on HTTPS), then overriding the domain works well, but in cases where you want to share or consume external data that may be passed over HTTP or HTTPS you'd probably want to stick with JSONP.

The Project Badge makes use of JSONP so it can work on your website. Most of my publicly available web services also make use of JSONP through a WCF JSONPBehavior.

The Project Badge displays your GitHub and Google Code projects in a badge that can be displayed on your site. This widget was built on the data being returned from my Open Source Service.

View this post outside your RSS reader to see it in action or view it here.

The source for the Project Badge can be found here and the source for the accompanying service can be found here. A list of all my publicly available web services can be found here.

Using The Project Badge On Your Website or Blog

1. Add The Asset References

Add the following asset references, and a reference to jQuery (if you don't have one already).

2. Configure Your Accounts

Set your project accounts (it's OK if you only use one host) then optionally set the appropriate filters - in my case my Google Code projects were prefixed with adamdotcom and I had duplicate projects on both GitHub and Google Code. By specifying remove:adamdotcom,remove:duplicate-items in my filters I filter out the duplicates and removed adamdotcom from the project name.

3. Add The Widget Hook
Add an element to your site or blog with the id of project-badge.

That's it!
If you have any issues, use the the working example as a reference, or send me a message.

How it works

If you have a project on GitHub or Google Code, you can retrieve your project details.

Single project host retrieval URI:

http://adam.kahtava.com/services/open-source/projects/{project-host}.{xml|json}?user={username}

Multiple project host retrieval URI:

http://adam.kahtava.com/services/open-source/projects.{xml|json}?project-host:username={project-host1:username1,project-host2:username2}

Example, requesting projects from Google Code in XML format:

Request: http://adam.kahtava.com/services/open-source/projects/googlecode.xml?user=adam.kahtava.com

Response:

Example, requesting projects from GitHub in JSON format:

Request: http://adam.kahtava.com/services/open-source/projects/github.json?user=adamdotcom

Response:

Example, requesting projects from both GitHub and Google Code in a single request in XML form:

Request: http://adam.kahtava.com/services/open-source/projects.xml?project-host:username=github:adamdotcom,googlecode:adam.kahtava.com

Response:

And Now What?

View my sidebar widget that uses this service to display the latest updates from my source code repositories here.

Contribute, view, or download this openly available source code here.

REST stands for Representational state transfer. REST is not an architecture, instead it's a set of design criteria. RESTfulness and RESTful web service try to make use of the full gambit of HTTP Methods (GET, PUT, POST, DELETE, OPTIONS, and HEAD), and try to expose every resource or operation in a meaningful URI / URL. RESTful web services are intuitive, and work similar to the way the human web works (meaningful semantic data is returned to the client, resources link to other resources, microformats are employed, and so on).

Qualities associated with RESTfulness:

• RESTful is the the way the human web works - where the data returned by services can be easily understood by humans (or robots) and usually contain links to other resources
• RESTful web services use varying response formats. Common formats include: XHTML pages, XHTML microformats, JSON, XML, ad-hoc HTML, JavaScript, or build your own
• RESTful web services depend on meaningful URIs. These URIs can contain scoping information, but shouldn't contain query requests. For example: when searching for 'kumquat' on Google you're redirected to http://www.google.com/search?q=kumquat where your search query is present in the URI. Whereas a URI like http://www.google.com/search/kumquat/ specifies the search parameters within the URI - this is not recommended as it implies some predictability, search results are unpredictable
• RESTful web services also use query variables as inputs to algorithms
• RESTful web services expose a URI for every piece of data the client may want to operate on
• RESTful web services make use of HTTP methods (GET, PUT, POST, DELETE, OPTIONS, and HEAD)
• RESTful web services don't keep the state on the server (that's the client's job), they don't like cookies, and don't like sessions
• RESTful web services make use of HTTP Headers

Examples of RESTful web services:

• Amazon S3
• Most of Yahoo!'s web services
• The Atom protocol

Qualities that are not RESTful:

• Most SOAP or other RPC-Style Architectures where XML messages are placed in the HTTP Body
• Frameworks that depend heavily on overloaded POSTs and XML (See Safety, Idempotence, and the Resource-Oriented Architecture for more information)
• Most big corporate web service frameworks are not RESTful. Some frameworks like WCF try to provide REST like functionality on top of a SOAP based API, but these add-ons can be obtuse and unRESTful.

Examples of unRESTful web services:

• The XML-RPC Flickr API
• The SOAP Flickr API
• The REST Flickr API - although the name implis REST, this API is designed more like an XML-RPC
• The delicious API

The growing popularity of web based MVC frameworks is providing a welcomed push towards RESTfulness and the simplicity that it brings, because working with the grain of the web (REST) makes life simpler and more semantically meaningful too. If you want to learn more about RESTful web services then check out Restful Web Services by Leonard Richardson and Sam Ruby.

The Enhanced Whois web service lets me know where my visitor are geographically located, provides filtering capabilities, and can act on referrals. This will allow me (or you) to personalize site greetings, hide my email address (or content) based on the visitor, and provide a unique personal experience. Alternately I can use this service as a classic Whois service.

How it works.

We're not anonymous on the internet and IP addresses are what uniquely defines your internet existence. Whois services let us determine the registrant of internet resources.

Using my Whois service you can:

View your enhanced whois record.

By the visitor's IP address (your IP) URI:

http://adam.kahtava.com/services/whois/enhanced.{xml|json}

Example:

Request: http://adam.kahtava.com/services/whois/enhanced.xml

Response (using my IP):

<WhoisEnhancedRecord xmlns="http://adam.kahtava.com/services/whois" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <City>Calgary</City>
  <Country>Canada</Country>
  <FilterMatches i:nil="true"/>
  <FriendlyMatches i:nil="true"/>
  <IsFilterMatch>false</IsFilterMatch>
  <IsFriendly>false</IsFriendly>
  <Organization>Shaw Communications Inc.</Organization>
  <StateProvince>AB</StateProvince>
</WhoisEnhancedRecord>

By the visitor's IP address specifying a referrer, and a filter URI:

http://adam.kahtava.com/services/whois/enhanced.{xml|json}?filters={filters,filters,...}&referrer={referrer}

Example:

Request: http://adam.kahtava.com/services/whois/enhanced/xml?filters=CA&referrer=Twitter

Response (from an IP owned by Google, with a filter for California, and a referrer of Twitter specified):

<WhoisEnhancedRecord xmlns="http://adam.kahtava.com/services/whois" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <City>Mountain View</City>
  <Country>United states</Country>
  <FilterMatches>
    <string>StateProvince</string>
  </FilterMatches>
  <FriendlyMatches>
    <string>google</string>
    <string>twitter</string>
  </FriendlyMatches>
  <IsFilterMatch>true</IsFilterMatch>
  <IsFriendly>true</IsFriendly>
  <Organization>Google Inc.</Organization>
  <StateProvince>CA</StateProvince>
</WhoisEnhancedRecord>

View your classic Whois record.

By the visitor's IP address (your IP) URI:

http://adam.kahtava.com/services/whois.{xml|json}

Example:

Request: http://adam.kahtava.com/services/whois.xml

<WhoisRecord xmlns="http://adam.kahtava.com/services/whois" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <DomainName>68.146.10.100</DomainName>
  <RegistryData>
  <AbuseContact> ... </AbuseContact>
  <AdministrativeContact i:nil="true"/>
  <BillingContact i:nil="true"/>
  <CreatedDate>2002-06-03</CreatedDate>
  <RawText> ... </RawText>
  <Registrant>
    <Address>Suite 800630 - 3rd Ave. SW</Address>
    <City>Calgary</City>
    <Country>CA</Country>
    <Name>Shaw Communications Inc.</Name>
    <PostalCode>T2P-4L4</PostalCode>
    <StateProv>AB</StateProv>
  </Registrant>
  ...
</WhoisRecord>

So... why is this useful?

This is the first step for this site's personalization - if I know where the user came from, where the user is geographically located, and have the capabilities to filter their Whois responses, then I can tailor my content to the user. For example: if someone from Google landed on my site I could mention that I'd love to work there and provide my email address and phone number, similarly if someone from Calgary landed on my site I could provide my public calendar of local events. The possibilities are endless.

This service will be wrapped by a JavaScript widget that will take care of the asynchronous service polling, but that sounds like another post.

Contribute, view, or download the openly available source code here.

How it works.

If you have a resume on LinkedIn and you've added services@adamdotcom.com as a contact then you can:

View your resume - retrieve your Resume by first and last name.

By first and last name URI:

http://adam.kahtava.com/services/resume/linkedin/{firstName-lastName}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/resume/linkedin/adam-kahtava.xml

Response:

<Resume xmlns="http://adam.kahtava.com/services/resume" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Educations>
    <Education>
      <Certificate>Computer Programming and Analysis</Certificate>
      <Institute>Seneca College of Applied Arts and Technology</Institute>
    </Education>
    <Education>
      <Certificate>Bachelor of Science (Honours), Computer Science</Certificate>
      <Institute>Trent University</Institute>
    </Education>
  </Educations>
  <Positions>
    <Position>
      <Company>Corbis ...

Wow that was exciting, so now what?

Well.. Head on over to my resume page. My resume is being pulled from LinkedIn through this very service.

Contribute, view, or download the openly available source code here.

My online portfolio is increasingly scattered through the internet (reviews and wishlist are on Amazon, source code on github / Google Projects, resume on LinkedIn, and so on). I've been working on a couple services that will eventually pull my portfolio together while keeping a single point of reference, and... I'm sharing these services.

Introducing my Amazon Web Service.

How it works.

Basically if you have a Wishlist or a Review list on Amazon you can:

Discover your profile - retrieve your ListId (for WishLists) or CustomerId (for Reviews):

Discovery URI:

http://adam.kahtava.com/services/amazon/discover/user/{user-name}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/amazon/discover/user/adam-kahtava.xml

Response:

<Profile xmlns="http://adam.kahtava.com/services/amazon" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <CustomerId>A2JM0EQJELFL69</CustomerId>
  <ListId>3JU6ASKNUS7B8</ListId>
</Profile>

View your Reviews - retrieve your Reviews by username or Amazon CustomerId.

By customerId URI:

http://adam.kahtava.com/services/amazon/reviews/id/{customerId}.{xml|json}

By username URI:

http://adam.kahtava.com/services/amazon/reviews/user/{user-name}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/amazon/reviews/id/A2JM0EQJELFL69.xml

Response:

<Reviews xmlns="http://adam.kahtava.com/services/amazon" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Review>
    <ASIN>0321125215</ASIN>
    <Authors>Eric Evans</Authors>
    <AuthorsMLA>Evans Eric.</AuthorsMLA>
    <Content>Through this book Evan's ...

View your Wishlist - view your Wishlist by username or Amazon ListId.

By listId URI:

http://adam.kahtava.com/services/amazon/wishlist/id/{listId}.{xml|json}

By username URI:

http://adam.kahtava.com/services/amazon/wishlist/user/{user-name}.{xml|json}

Example:

Request: http://adam.kahtava.com/services/amazon/wishlist/user/adam-kahtava.json

Response:

[{"ASIN":"0471467413","Authors":"Mostafa Abd-El-Barr, Hesham El-Rewini", ...

So now what?

Head on over to my Reviews and Reading List pages. These pages make use of the data from this service. I should also mention that, this service was built on a previous iteration of my Amazon Web Service (How To Display Your Amazon Reviews and Wish List Using Amazon’s Web Services).

Contribute, view, or download the openly available source code here.