The Amazon Flexible Payments Service (FPS) looks like a great addition to the payment services arena, and if it’s anywhere near as popular as their other services have been then this one will surely be a huge success. I’m planning on using it for Monoh as the rates are significantly less than those of both PayPal and Google Checkout, and their API looks like it offers more functionality through a cleaner interface.

When I first started looking into using FPS with Ruby, I downloaded Amazon’s sample code, but was quickly discouraged by the complexity of their sample. My disappointment basically boils down to a deap-seated hatred for SOAP, and when you throw encryption with X.509 into the mix, it just becomes way too verbose for my liking, and doesn’t really fit in with the Rubyist philosophy.

Then I discovered that there’s a REST version of the API available, and offers nearly all of the functionality of the SOAP API. I don’t know why they seem to be hiding the REST capabilities, especially after talking to Brian LeGros and hearing from him that the majority of applications consuming Amazon services are using REST. Every sample they’re provided for FPS uses SOAP, except for a single REST example done with Java of all languages.

So I’ve begun working on a Ruby API for FPS over REST, and things are progressing fairly nice now that I’ve gotten over a silly snag that I had early on in the development. I’ve come up with a clean way to implement each action in the API and still keep things pretty DRY. I’m planning on releasing the API once I get the core of the API wrapped up, and I’ll try to post more about the development process as it progresses.

1 Response to “Amazon FPS in Ruby”

  1. Brian LeGros Says:

    Just so people don’t think I’m crazy, I heard the stats about Amazon’s web services on Software Engineering Radio (SER) episode #40 (http://www.se-radio.net/index.php?post_id=157593). I’m not sure if he was talking about the FPS stuff, but general usage from what I remember was about 70% of all users on REST and the remainder on SOAP-based services. I can see SOAP-based messaging possibly effective is they incorporate some of the new WS-* standards for stuff like transactions and reliable messaging, but otherwise, REST is so much easier for the average scenario why not take advantage. Keep up the great work Tyler!

Sorry, comments are closed for this article.