Tag: web services

I'm really enjoying working with WSE 3.0, especially its policy mechanism. It allows for Aspect Oriented Programming (AOP) through SoapFilters, enabling me to add functionality like security, auditing, and exception handling via configuration rather than hardcoding it into my web service. This keeps my service code clean and maintainable. I demonstrated this with a simple example of an OrderService, comparing the cleaner policy-based approach to a more complex, hardcoded alternative. The policy configuration significantly simplifies adding and managing cross-cutting concerns.

This post is a follow-up to my earlier one about using SOAP requests in ASP.Net to access the eBay API. I've finally figured out how to make it work! A few key things to note: most requests need the "version" attribute, some require the "DetailLevel" attribute, and you'll need an eBay Authentication Token (a cryptographic hash) for security. When using the WSDL URL, remember to include query string parameters so eBay knows what to do. I've included some sample C# code demonstrating how to build the request URL, set credentials, and handle the response.

I recently discussed the lack of retail web service APIs for major companies like Tesco, Dixon's, and HMV. I've since discovered an ASDA Soap API on maskell.uk.com. I'm impressed by this development, though I'm uncertain how it's implemented (possibly screen scraping). Check it out!

Inspired by my recent success binding XAML directly to Amazon's web service, I'm exploring the possibility of extending this approach to other RESTful services. Imagine building applications, like my AJAX Tagger, entirely in XAML, without any C# code. This hinges on WPF's capabilities. Do you think it's feasible?

I'm consistently impressed by Yahoo's web service team and their responsiveness to users. In contrast, Amazon's web service support is practically non-existent. My simple question about UK support for the TextStream parameter in AWS has gone unanswered for ages, and I know I'm not alone. Amazon, please step up your game!

I'm excited to announce that DeliTag will be featured on the main page to increase visibility and usage. It will also be available on Tagger.Kinlan.co.uk. As a reminder, DeliTag is an AJAX-based mashup of Yahoo and Del.icio.us, allowing users to generate and post tags to Del.icio.us based on page content.

I've been exploring the Amazon Web Service API, comparing its REST and SOAP interfaces. Initial impressions suggest the REST API is significantly faster, especially compared to my experiences using the SOAP API with C# and Web References. However, it's worth noting that these observations aren't based on rigorous testing and the different environments (Windows Forms vs. a Linux server on a fast network) could be influencing the perceived performance difference.

I'm planning to transform my AJAX Tagger into a WinFX application to experiment with its potential and integrate various web services.

I've always struggled to find good directories of companies offering web services. I finally stumbled upon ProgrammableWeb (http://www.programmableweb.com/apis), which has a pretty good list of major web APIs. However, it also highlights the disappointing scarcity of companies providing decent APIs for developers.

In part two of this series on the failures of my first AJAX application, I discuss how my initial plan to reduce bandwidth by having the client directly access third-party web services didn't work out. Due to cross-domain scripting issues in Firefox and IE 6/7, I had to implement proxy scripts on my server. This means all client requests now go through my server, increasing my bandwidth demands. While using a proxy server offers benefits like hiding security information (like Technorati developer tokens) and enabling data manipulation/request merging, it comes with the major downside of increased bandwidth usage and the need to create/maintain proxy scripts. I hope to support cross-domain data sources in the next version to mitigate these issues but acknowledge there might still be scenarios where proxy scripts are necessary.

This post, part 8 of a series about my first AJAX application, discusses my return to Perl programming after a year of focusing on C# and .Net. I needed to solve cross-domain scripting issues when calling a web service directly from the webpage. My solution involved proxying the request through a Perl script on my server, which also hid my developer tokens. I found Perl's libraries easy to use and effective for this task. Future plans include more Perl scripting to aggregate data from different blogs and web services, leveraging the proxy to combine multiple calls and enhance functionality. I also learned a valuable lesson about using "content()" methods for POST operations instead of the query string.

In this part of my series on my AJAX application, I'm discussing the impact of external APIs. My use of APIs has made me realize how much more API access I want! I'd love to see broader API availability from feed/blog companies for statistics, retail companies for catalogs, news corporations for news feeds, and search companies for both results and more interesting APIs (like Yahoo's). Essentially, I want a central directory of companies offering these services, recognizing that I'm a consumer of their data. I'm also realizing how many APIs (REST and SOAP) are out there that I could leverage. I envision adding more dynamism to my apps, like analyzing blog post keywords to see their popularity, potential ad revenue, and related keywords. I could then cross-reference this with other sources to give viewers more feedback, such as related blog importance, link counts, and other connections. I could even offer localized product information, best buy deals, or second-hand options based on keywords. This isn't revolutionary, but I need help finding lists of companies that offer web APIs and useful RSS feeds. Readers, please share your knowledge!

I believe retailers need to embrace open APIs to their product catalogs and ordering systems to reach a wider audience. While I agree with Robert Scoble's view on the transformative potential of developer APIs in retail, I'm concerned about the slow pace of change. Costly per-call charges for APIs like eBay's hinder experimentation and development, especially for independent developers like myself. It's also difficult to find retailers who openly offer APIs. Amazon's free access model is a good example of how APIs can drive revenue. Are there any UK retailers offering cool, accessible web services?

This is the fourth installment of my AJAX application development journey. I integrated the Technorati API, focusing on the Tag Query to gauge keyword popularity and refine tag selection for better exposure. While the API was helpful, it lacked features like tag ranking and related tags, and the TagQuery's slow performance forced its removal. Future development will involve optimizing the TagQuery (limiting results or using an asynchronous call manager) and potentially requesting a lightweight metadata interface from Technorati.

This blog post presents the results of my initial experiment with Amazon Web Service. I've compiled a list of various products, including books and a DVD, with links to their respective pages on Amazon.co.uk. This appears to be an early exploration of the possibilities of integrating Amazon's product data.

I'm exploring different web services, particularly for UK retailers like Tesco, Asda, or Virgin. I've tried Amazon's, which is decent, and Yahoo's, which I like. Ebay's looks interesting, but I'd rather not pay. I'm also looking at Alexa's and Google's. It's tough finding good resources on this, especially for UK retailers. I'd love to see APIs from companies like Tescos, Asda, Dixons, and others. If you know of any good web services, especially in the UK retail space, please share!