I was pleased to see recently that the NOAA was providing forecast
data in XML. I was disappointed to see that the query mechanism was
SOAP. Allow me to rant for a moment: SOAP is a bit of an atrocity.
SOAP is the "simple object access protocol" which is this abomination
in which you tunnel gigantic XML wrapped queries over HTTP in order to
access various web services. Then, XML documents are returned.
Great, I'm all for XML in appropriate places. If you're accessing a
web service that is returning structured data, an XML document is
almost the perfect response. However, an XML query?
Why? Why? Ok, I know some of the reasons, but when it comes down to
it, they're not very good. Just because you can beat a nail into the
wall with the end of a screwdriver doesn't make it the right tool for
the job. If only we had a straightforward method for requesting named
objects with arbitrary named parameters as a query, right? We do.
It's called HTTP and url-encoded form data. So, if I have a really
simple object "myObject" I want to call "myMethod" on with the named
parameter "myParameter" with a value of "myValue", in SOAP, I have to send:
POST /myProxy HTTP/1.1
standard HTTP headers removed for clarity
SOAPAction: "urn:myObject#myMethod"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/1999/XMLSchema"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<namesp1:myMethod xmlns:namesp1="urn:myObject">
<myParameter xsi:type="xsd:string">myValue</myParameter>
</namesp1:myMethod>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
in contrast, if I were to use just a URL, it might look something like this:
GET /myProxy/myObject/myMethod?myParameter=myValue HTTP/1.1
standard HTTP headers removed for clarity
Both approaches return the exact same data. SOAP, I have to use third
party libraries which may be incomplete, poorly documented or buggy.
In the latter approach, I can use curl, lynx, wget, any web
browser, third party libraries or I can hack together a raw
socket implementation in minutes. Some people have taken to calling
this latter approach "REST" which refers to Fielding's
"Representational State Transfer". I'm fine with calling it REST if
the goal is to have a name for it but the real name for it is "the
world wide web". Having a queryable URL which returns XML is great.
Having to send it XML in the first place is unnecassary. Emerson
commented: "A foolish consistency is the hobgoblin of small minds."
I'm sure this is exactly what he was thinking of. XML is cool, but
let's not over apply it til we get sick of it. WSDL is cool, but
let's just skip section 3 (SOAP binding) and focus on section 4 (HTTP
binding). If you have a strong reason to use SOAP rather than
straight HTTP, go ahead, but in essentially every case I've ever seen,
an HTTP binding would be more than sufficient and vastly superior.
Ok, the rant part is over.
So, in an effort to make the world a better place, I made a RESTish
HTTP gateway to the NOAA SOAP interface.
The URL is http://mkgray.com:8000/noaaforecast and it take parameters longitude, latitude, product, optionally startTime, optionally endTime and at least one of the weather parameters (maxt, mint, temp, dew, pop12, qpf, snow, sky, wspd, wdir, wx, icons, waveh) if you are using time-series mode. For example, if you wanted to see what was forecast to fall out of the sky near Boston:
If you hit the page too often (more than 30 times in a 6 hour period) you'll be throttled and given 503 errors. If you omit latitude, longitude, product or parameters when required, you'll get a 404. See the NOAA page for details on the format of the inputs (ie, the times) and the format of the returned XML.
No comments:
Post a Comment