Archive

Archive for the ‘WCF’ Category

Open Source Service Updates: Google Code’s New Project Page

January 13th, 2011
Github or Google Code Source Code Repository Project Badge

My Open Source Service is fixed. The problem being that Google Code’s profile page changed and the project list wasn’t being populated – man, I wish Google Code had an API. Anyhow; I added more tests, reduced some technical debt, cleaned up my page sniffer / scraper and things are working again. The Open Source Service is consumed by my Project Badge (image on the right). Check out the source code updates.

Author: Adam Kahtava Categories: .NET, ADC Services, Open Source, RESTful, Services, WCF, XML Tags:

Whois Service Updates: ARIN’s New RESTful API

December 7th, 2010

My Whois Service is fixed. The American Registry for Internet Numbers (ARIN) released a fantastic new RESTful API which meant my old text parsing code (dependent on their old service) was broken for a couple weeks. Check out the new ARIN RESTful API and my service source code updates.

Author: Adam Kahtava Categories: .NET, ADC Services, Open Source, RESTful, Services, WCF, XML Tags:

The Same Origin Policy: JSONP vs The document.domain Property

March 18th, 2010

The Same Origin Policy ensures that the client-side code (JavaScript) running on a website originated from that website. This prevents website http://kahtava.com from accessing resources (via client-side code) on website http://malicious-password-sniffers.com or website http://adam.kahtava.com from executing resources from http://kahtava.com - note that the sub-domains differ, one being kahtava.com, the other being adam.kahtava.com

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:

JAVASCRIPT:
  1. (function(){
  2.   $.getJSON('http://adam.kahtava.com/services/open-source/projects.json?project-host:username=github:adamdotcom&callback=?', function(data) {
  3.     alert(data);
  4.   });
  5. })();

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:

JAVASCRIPT:
  1. (function(){
  2.   document.domain = 'kahtava.com';
  3.   $.get('http://adam.kahtava.com/contact-me/', function(data) {
  4.     alert(data);
  5.   });
  6. })();

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.

Introducing my Open Source Projects Service: Grab Your Project Details From GitHub or Google Code

February 11th, 2010

Say hello to the newest member of my service family; the Open Source Project Service. This service lets me (and you too my friends) grab our project details from either Google Code, or GitHub.

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:

XML:
  1. <Projects xmlns="http://adam.kahtava.com/services/open-source" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  2.   <Project>
  3.     <Description>The site source in use on Adam.Kahtava.com / AdamDotCom.com (http://adam.kahtava.com/)</Description>
  4.     <LastMessage>More code coverage on controllers required!! :)</LastMessage>
  5.     <LastModified>2010-02-26</LastModified>
  6.     <Name>website</Name>
  7.     <Url>http://code.google.com/p/adamdotcom-website</Url>
  8.   </Project>
  9.   ...
  10. </Projects>

Example, requesting projects from GitHub in JSON format:

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

Response:

JAVASCRIPT:
  1. [
  2.   {
  3.     "Description":"A collection of my etcetera, so forth, and so on. Contains a PowerShell script for Twitter, a programming exercise in Ruby, a programming exercise for Google done in JavaScript.",
  4.     "LastMessage":"Bing-bing, changing filenames",
  5.     "LastModified":"2009-06-08",
  6.     "Name":"scripts",
  7.     "Url":"http:\/\/github.com\/AdamDotCom\/scripts"
  8.   },
  9.   ...
  10. ]

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:

XML:
  1. <Projects xmlns="http://adam.kahtava.com/services/open-source" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  2.   <Project>
  3.     <Description>Displays your public source code repositories from Google Code and GitHub.</Description>
  4.     <LastMessage>Added http://code.google.com/p/adamdotcom-services/ link</LastMessage>
  5.     <LastModified>2010-02-23</LastModified>
  6.     <Name>project badge</Name>
  7.     <Url>http://github.com/AdamDotCom/project-badge</Url>
  8.   </Project>
  9.   ...
  10.   <Project>
  11.     <Description>The site source in use on Adam.Kahtava.com / AdamDotCom.com (http://adam.kahtava.com/)</Description>
  12.     <LastMessage>More code coverage on controllers required!! :)</LastMessage>
  13.     <LastModified>2010-02-26</LastModified>
  14.     <Name>website</Name>
  15.     <Url>http://code.google.com/p/adamdotcom-website</Url>
  16.   </Project>
  17.   ...
  18. </Projects>

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.

Author: Adam Kahtava Categories: .NET, ADC Services, Open Source, RESTful, Services, WCF, XML Tags:

RESTful Web Services: What Are They?

December 4th, 2009

RESTful web services are all the rage these days, and for good reason. Many web based MVC frameworks depend on REST. Here's a crash course on what RESTful web services are and aren't.

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:

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 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.

Author: Adam Kahtava Categories: ASP.NET MVC, RESTful, Services, WCF Tags:

Introducing my Whois Service: Customize Your Site Content Based On Referrals, Location, and More

September 30th, 2009

Services-services-services! Enough already! Today I introduce my Whois and Enhanced Whois Web Service.

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

Response (using my IP):
<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.

Author: Adam Kahtava Categories: .NET, ADC Services, Open Source, RESTful, Services, WCF, XML Tags:

Introducing my LinkedIn Resume Service: View Your Resume

September 24th, 2009

In my last post I mentioned that I was creating a couple web services that would hopefully bring together my online portfolio. Today I introduce my LinkedIn Resume Web Service.

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.

Author: Adam Kahtava Categories: .NET, ADC Services, Open Source, RESTful, Services, WCF, XML Tags:

Introducing my Amazon Web Service: Find Your Profile, View Your Wishlist or Reviews

September 15th, 2009

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.