On Sun, December 17, 2006 8:44 pm, jonathan wrote:
I'm working on a project where we'd want partner sites to get our
content on the other web sites.
Might I suggest that you support several options?...
A key priority is that they won't have much technical sophistication
(probably no db experience or php experience).
Offering more formats gives the partners more options to choose what
suits their experience/needs/skills.
Also, these would be third party sites so there would also be an
issue of requirements (differnet xsl processors,
no allow_url_fopen, etc...)
Without allow_url_fopen(), you're down to curl or no PHP at all, with
an iFrame or JS...
I tried looking at sites that get their content on other sites to see
how they do it:
the possible solutions seem to be:
1. rss / xml - this is well known but would have a pretty high
technical hurdles on the other sites. We could create
every walk through and code sample but I still think it would be too
involved. Only way out is either a xsl transformation (not
going to happen), custom parsing library in php (maybe) or writing to
db with associated libraries (too complex)
You should probably provide your content as RSS, no matter what else
you do, because it's so ubiquitous.
Assuming your content is in a db, dumping out an RSS feed is pretty
much a no-brainer, really.
2. serialized php with custom library - this seems more feasible than
#1 in terms of requirements
I don't even know what this means...
3. php proxy and ajax call / json - i think this would be too complex
and would require too much manipulation of apache to handle
subdomains, etc.
I can sort of see where you are going, where they'd use Ajax to input
the parameters of the content they want, but, really, just a
well-designed GET and an iFrame or Ajax or whatever the partner wants
to use to snarf and display the content is probably easier.
4. included javascript - kinda how digg handles syndication (see
http://www.digg.com/add-digg for example).
This would seem to be the lowest barrier to entry. The main concern
is preventing unauthorized bots from crawling. It would seem
our only option would be using the referer property but this could be
forged relatively easily.
It's very common to require a username/password in the URL for content
partners.
And you can require them to pre-register the IP of their server[s]
that will be crawling for the content -- Only their servers need to
access your content, not all their visitors' machines. So they are
static IP and they should not have TOO many of them to register, even
in a mutli-data-center setup.
I worked for a content aggregator for awhile, and virtually all their
content partners required a username/password in the URL, and we had
to register the IPs of the servers that were getting the data. I
suppose you could do a reverse DNS lookup and cache the results, but,
really, it's easier to get the IP address up front.
5. SOAP - no way
Again, if you have the db already, and if you have PHP5, this is
actually not difficult at all to implement on your side.
So maybe it only helps you get one more content partner (sale) that
loves using SOAP instead of RSS or whatever.
It's a pretty small investment on your side, for relatively good odds
on payoff.
It's a bit tougher in PHP4, though there are libraries out there that
can take care of 99% of it.
6. REST - if meant to just mean xml, i see this as an extension of #1.
Somewhere between #1 and #5, sort of.
Same answer though.
A PHP REST library and a couple hours of hacking and a couple days of
serious development and a couple weeks of hard-core QA, and you're
good to go.
So I'm suggesting that you could support MOST of the above, probably
with the same core set of functions and minimal effort for the output
layers:
RSS / XML
SOAP
REST
You could also provide a nice CSS Zen Garden span/div only HTML output
for an iframe so that a CSS hack could make decent output.
Perhaps even a CSV or tab-delimited data dump for somebody who wants
to store-and-forward the data.
If you plan well, you could build the application so that you can roll
out a new API layer every month or so, and not have to do *ALL* of
them from the get-go, but always be in touch with your partners,
bragging on yourself about how you now support XYZ and giving them
more options and the warm fuzzies about how much you cater to them.
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
