 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
http://asserttrue.blogspot.com/2009/04/api-first-design.html
Huh? Doesn't everyone document the APIs before they start writing code that
exports APIs? Seriously, don't you programmers do that?
I can't imagine how you can even know when you're done a piece of the
library if you didn't do the documentation first. I thought that was, like,
the only way to do it.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> http://asserttrue.blogspot.com/2009/04/api-first-design.html
>
> Huh? Doesn't everyone document the APIs before they start writing code
> that
> exports APIs? Seriously, don't you programmers do that?
>
> I can't imagine how you can even know when you're done a piece of the
> library if you didn't do the documentation first. I thought that was,
> like, the only way to do it.
I spent weeks deciding on the API, some more weeks deciding on internal
design, and I've yet to write any *real code* for this one library... :)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> http://asserttrue.blogspot.com/2009/04/api-first-design.html
>
> Huh? Doesn't everyone document the APIs before they start writing code
> that exports APIs? Seriously, don't you programmers do that?
>
> I can't imagine how you can even know when you're done a piece of the
> library if you didn't do the documentation first. I thought that was,
> like, the only way to do it.
Maybe I don't do anything enterprisy enough. I'm usually more worried
about "Jesus, how the hell do you design an algorithm does solves X?"
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> Maybe I don't do anything enterprisy enough.
I think the commentators use "API" to mean "external API to access your
webby crap." It used to be that "API" was how you interface to pretty much
any chunk of library code.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> Orchid XP v8 wrote:
>> Maybe I don't do anything enterprisy enough.
>
> I think the commentators use "API" to mean "external API to access your
> webby crap." It used to be that "API" was how you interface to pretty
> much any chunk of library code.
It's news to me that it's possible to access anything web-based with
something other than a web browser.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible <voi### [at] dev null> wrote:
> It's news to me that it's possible to access anything web-based with
> something other than a web browser.
Why would the http protocol be limited to web browsers?
--
- Warp
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> It's news to me that it's possible to access anything web-based with
> something other than a web browser.
Tell Windows Live Mail to use your Hotmail account and it will talk over
http.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
>> It's news to me that it's possible to access anything web-based with
>> something other than a web browser.
>
> Tell Windows Live Mail to use your Hotmail account and it will talk over
> http.
That's because they are both Micro$oft products.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Warp wrote:
> Invisible <voi### [at] dev null> wrote:
>> It's news to me that it's possible to access anything web-based with
>> something other than a web browser.
>
> Why would the http protocol be limited to web browsers?
It isn't. I personally have written a small Haskell program that
connects to PassMark website, downloads the current benchmark table, and
gives me a CSV file containing all the current results.
Of course, writing an HTTP client is very nontrivial. If anything
remotely unusual were to happen, my program would hopelessly fall over.
More to the point, there's masses of tricky parsing to wade through all
the presentational HTML to extract the actual raw data I'm after.
(The original plan was to then connect to ebuyer.com and dredge out the
processor prices and availability - but this turned out to be far too hard.)
The fun part is, if PassMark ever change their presentational HTML (or
their URLs), my program will spectacularly break.
I wouldn't really call this "interfacing my program to a website". I'd
call this "a fragile hack which just happens to sort-of work right now".
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> That's because they are both Micro$oft products.
Not really, it's because there is an agreed standard for how the information
is transferred over http (of course if both sides are made by the same
company this is usually automatically the case).
How about RSS feeds, loads of programs written that access those over the
web?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
>> That's because they are both Micro$oft products.
>
> Not really, it's because there is an agreed standard for how the
> information is transferred over http (of course if both sides are made
> by the same company this is usually automatically the case).
Well, let's face it, any system is merely an agreed way to send data
between multiple computers. I'm just saying, I'm not aware of any way of
accessing an arbitrary website programatically without going through a
world of pain.
> How about RSS feeds, loads of programs written that access those over
> the web?
I don't what what RSS is.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> I don't what what RSS is.
http://tinyurl.com/ct6woq
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
>> I don't what what RSS is.
>
> http://tinyurl.com/ct6woq
Oh, the Wikipedia article on RSS. I would *never* have thought of that. :-P
Seriously, did you think I hadn't read that already?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Nicolas Alvarez <nic### [at] gmail com> wrote:
> Darren New wrote:
> > http://asserttrue.blogspot.com/2009/04/api-first-design.html
> >
> > Huh? Doesn't everyone document the APIs before they start writing code
> > that
> > exports APIs? Seriously, don't you programmers do that?
> >
> > I can't imagine how you can even know when you're done a piece of the
> > library if you didn't do the documentation first. I thought that was,
> > like, the only way to do it.
>
> I spent weeks deciding on the API, some more weeks deciding on internal
> design, and I've yet to write any *real code* for this one library... :)
From my experience, a *typical* real-life working mode would be to
(1) design and (optionally) document the API
(2) design and (optionally) document the internal design, modifying the API as
problems with the internal design arise
(3) write the real code, modifying both the internal design and API as problems
with the real code arise
(4) start working on a new project
(5) (optionally) document the changes made to the API in phases (2) and (3)
(6) (optionally) document the changes made to the internal design in phase (3)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
clipka wrote:
> From my experience, a *typical* real-life working mode would be to
<chortle> I think you hit the nail on the head.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> More to the point, there's masses of tricky parsing to wade through all
> the presentational HTML to extract the actual raw data I'm after.
That's because you're getting the results in HTML instead of "via an API".
That's what people are talking about when they talk about web APIs:
presenting data without making you parse it.
"REST" is a pattern for doing this in a way that *also* lets you use a web
browser to reverse-engineer the protocols by looking at it and which is
theoretically kind to intermediate proxies.
"SOAP" is a pattern for doing this in a way that lets you publish the
specification of the interface in a form that a tool can generate code to
decode it into whatever native data structures are available for your language.
What you're doing is called "screen scraping", and yes, it breaks when the
format of the web page changes, which happens often when there's so many
people doing screen scraping that it starts to impact the actual customers
of the web site.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> accessing an arbitrary website programatically without going through a
> world of pain.
No, you can't access "arbitrary" websites that present HTML. Well, you can,
depending on what you want to do. Google does it all the time. But it's hard
to get specific information out in an automated way. That's why people
invented HTTP-based APIs like SOAP.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> accessing an arbitrary website programatically without going through a
>> world of pain.
>
> No, you can't access "arbitrary" websites that present HTML. Well, you
> can, depending on what you want to do. Google does it all the time.
Uhuh. And how many PhDs work for Google?
> But
> it's hard to get specific information out in an automated way. That's
> why people invented HTTP-based APIs like SOAP.
Why would you base a protocol on HTTP?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> Invisible wrote:
>> More to the point, there's masses of tricky parsing to wade through
>> all the presentational HTML to extract the actual raw data I'm after.
>
> That's because you're getting the results in HTML instead of "via an API".
>
> That's what people are talking about when they talk about web APIs:
> presenting data without making you parse it.
>
> "REST" is a pattern for doing this in a way that *also* lets you use a
> web browser to reverse-engineer the protocols by looking at it and which
> is theoretically kind to intermediate proxies.
>
> "SOAP" is a pattern for doing this in a way that lets you publish the
> specification of the interface in a form that a tool can generate code
> to decode it into whatever native data structures are available for your
> language.
So you mean you get the web server to search an XML document so the
client at the other end can parse it into something useful more easily?
> What you're doing is called "screen scraping", and yes, it breaks when
> the format of the web page changes, which happens often when there's so
> many people doing screen scraping that it starts to impact the actual
> customers of the web site.
I doubt my one hit per month hurts PassMark. ;-)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> So you mean you get the web server to search an XML document so the
> client at the other end can parse it into something useful more easily?
s/search/serve
Yes.
> I doubt my one hit per month hurts PassMark. ;-)
No, but when people distribute software that (for example) takes TV listings
off Yahoo's web site without grabbing or showing any ads, and 100,000 people
run that every day, Yahoo notices.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> Uhuh. And how many PhDs work for Google?
Lots. So? It's not hard to make a web crawler, as long as you're not trying
to understand data that *isn't* presented in HTML tags. How hard is it to
find all the URLs in a HTML document?
>> But it's hard to get specific information out in an automated way.
>> That's why people invented HTTP-based APIs like SOAP.
>
> Why would you base a protocol on HTTP?
Because it's easy and the standards are there to say how to look things up
and encode the bytes and do the logging in and encryption and things like
that. If you have a request/response model, it's not a bad protocol. If you
have something more complex than a request/response model, you should be
using something like BEEP.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> So you mean you get the web server to search an XML document so the
>> client at the other end can parse it into something useful more easily?
>
> s/search/serve
>
> Yes.
Hmm. Interesting.
Does anybody ever do this?
>> I doubt my one hit per month hurts PassMark. ;-)
>
> No, but when people distribute software that (for example) takes TV
> listings off Yahoo's web site without grabbing or showing any ads, and
> 100,000 people run that every day, Yahoo notices.
It's news to me that Yahoo is still in business...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> Does anybody ever do this?
Um, yes, scads of people. For example, the whole Amazon "cloud computing" is
based on this, Yahoo does it for their search engines, iTunes does it for
music search, Google has APIs for the stuff they do, Amazon lets you search
and buy and sell things that way, etc.
> It's news to me that Yahoo is still in business...
Do you do this on purpose? :-) I mean, you don't even have to google
anything to figure out if Yahoo is still running a web site.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
>> Does anybody ever do this?
>
> Um, yes, scads of people. For example, the whole Amazon "cloud
> computing" is based on this, Yahoo does it for their search engines,
> iTunes does it for music search, Google has APIs for the stuff they do,
> Amazon lets you search and buy and sell things that way, etc.
...wait, so you mean there's a way I can use this to find out how much
money Amazon want for product X?
>> It's news to me that Yahoo is still in business...
>
> Do you do this on purpose? :-) I mean, you don't even have to google
> anything to figure out if Yahoo is still running a web site.
I'm not disputing that Yahoo are still going - clearly they are - I'm
just saying it's news to me. As in, nobody ever speaks about them any
more...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> ...wait, so you mean there's a way I can use this to find out how much
> money Amazon want for product X?
Yes.
Look at "amazon web services" on wikipedia for a list of all their APIs. The
"associates" API is what you're looking for.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> Orchid XP v8 wrote:
>> ...wait, so you mean there's a way I can use this to find out how much
>> money Amazon want for product X?
>
> Yes.
>
> Look at "amazon web services" on wikipedia for a list of all their APIs.
> The "associates" API is what you're looking for.
Heh. Too bad Amazon don't sell CPUs. I might actually be able to write
my price/performance autoplot tool after all. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> scott wrote:
>> How about RSS feeds, loads of programs written that access those over
>> the web?
>
> I don't what what RSS is.
http://blog.orphi.me.uk/feed
Open it with a text editor. Isn't it easier to parse than all the
presentational HTML in your blog?
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Orchid XP v8 wrote:
> Heh. Too bad Amazon don't sell CPUs.
No, but they'll rent them to you. ;-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |