Hi Davey,
What you have proposed makes a lot of sense (and those lunchtime changes would be nice!). I'm willing to forgo a Technorati proposal pending your own development. I guess I just wonder about pushing the API knowledge down the line but maybe that's me - I like simplicity a little too much ;). I would prefer to have something specific to the web service rather than relying on knowledge of the API.
Nevertheless, given Technorati's API is relatively straight forward I see where you're coming from.
Regards,
Pádraic
Pádraic Brady
http://blog.quantum-star.com
What you have proposed makes a lot of sense (and those lunchtime changes would be nice!). I'm willing to forgo a Technorati proposal pending your own development. I guess I just wonder about pushing the API knowledge down the line but maybe that's me - I like simplicity a little too much ;). I would prefer to have something specific to the web service rather than relying on knowledge of the API.
Nevertheless, given Technorati's API is relatively straight forward I see where you're coming from.
Regards,
Pádraic
Pádraic Brady
http://blog.quantum-star.com
----- Original Message ----
From: Davey Shafik <[EMAIL PROTECTED]>
To: Pádraic Brady <[EMAIL PROTECTED]>
Cc: fw-general@lists.zend.com
Sent: Thursday, September 21, 2006 5:37:18 PM
Subject: Re: [fw-general] Additional Web Services?
Personally,
From: Davey Shafik <[EMAIL PROTECTED]>
To: Pádraic Brady <[EMAIL PROTECTED]>
Cc: fw-general@lists.zend.com
Sent: Thursday, September 21, 2006 5:37:18 PM
Subject: Re: [fw-general] Additional Web Services?
Personally,
I am of the opinion that there are simply far too many web services for us to implement APIs for all of them. The few that we should implement should be:
a) Complex to use (the service, not our API!) or extensive
b) Commonly used by lots of developers
c) Not a moving target - versioning and maturity ensure our code doesn't get out dated.
d) Wrappers for multiple similar services
They don't need to fulfill all of the above, but pick 3 at least :)
Simple/minimal APIs should be handled by either 3rd party packages (and maybe a wiki page that lists them) or by
the individual developer using the upcoming Zend_WebService components being written by Matthew and myself.
WIth my new REST client, I have this:
$technorati = new Zend_Rest_Client('http://api.technorati.com/bloginfo');
$technorati->key($key);
$technorati->url('http://pixelated-dreams.com');
$result = $technorati->get();
echo
$result->document->result->weblog->author->firstname .' '. $result->document->result->weblog->author->lastname;
This is still very much a work in progress. At lunch today I will change it so that the last line is not so ugly (this is because currently a SimpleXML document is returned for non-Zend_Rest_Server services). So, it'll be:
echo "$result->firstname $result->lastname";
And no, I'm not making special provisions for Technorati, but you /will/ need to know your API before hand, otherwise the above could result in "Array Array" ;)
Also, I want to note that it does have a "fluent" API, so you can do:
$result = $technorati->key($key)->url("http://pixelated-dreams.com")->get();
I say "fluent", because whilst it works technically like a fluent API, its not close to human readable, if the service doesn't work that way (in this case :)
I could make this more fluent using something like:
$result = $technorati->action('bloginfo')->usingKey($key)->withUrl('http://pixelated-dreams.com')->get();
where the 'using' and 'with' are just prefixes to make it 'read' nicer. They are discarded. This of course causes a problem with what if you have a web service that uses those in their name. So I don't think this is a good idea ;)
I guess no matter what you do, unless you use the __ prefix (which only reduces the risk), there is always the potential for clashes between the code API and the Web Service API when using overloading. Such is life. :)
- Davey
On Sep 21, 2006, at 8:48 AM, Pádraic Brady wrote:
Hi,
I was considering raising a proposal for adding several additional web services I (at least) will be needing at some point in the future. It would be nice to add them to the Framework if they were acceptable. Suggestions would be:
- Exchange Rates (several sources, incl. UN, ECB and FRB)
- Technorati API
I thought I'd throw these two suggestions out there and see what folk thought about them. If they are deemed worthwhile adding to the Framework I'm willing to put together a proposal for at least one of them.
FYI: these are present in some form (even if only alpha) on PEAR. Haven't used PEAR's Exchange Rates implementation but it seems to cover the main sources in a Beta dated last November.
Thoughts?
Best regards,
Pádraic
Pádraic Brady
http://blog.quantum-star.com