I was talking to the author of a book on REST the other day, and noticed that neither HTTPClient nor HTTPSocket really seem to support REST APIs. At a bare minimum, I think you'd probably want the ability to add arbitrary headers to GET/PUT/POST (which HTTPSocket doesn't allow) and the ability to issue DELETE commands. For example, Amazon's APIs require an Authorization: header, and writing a clean WebDAV client that didn't duplicate a huge chunk of HTTPSocket functionality would be impossible at the moment. I'd be happy to submit a changeset refactoring HTTPSocket to make this more feasible, but I wanted to verify that I'm not either misunderstanding how these classes are supposed to be used or missing existing functionality already in the image.
Cheers, --Benjamin
On 3/21/07, Benjamin Pollack benjamin.pollack@gmail.com wrote:
I was talking to the author of a book on REST the other day, and noticed that neither HTTPClient nor HTTPSocket really seem to support REST APIs. At a bare minimum, I think you'd probably want the ability to add arbitrary headers to GET/PUT/POST (which HTTPSocket doesn't allow) and the ability to issue DELETE commands. For example, Amazon's APIs require an Authorization: header, and writing a clean WebDAV client that didn't duplicate a huge chunk of HTTPSocket functionality would be impossible at the moment. I'd be happy to submit a changeset refactoring HTTPSocket to make this more feasible, but I wanted to verify that I'm not either misunderstanding how these classes are supposed to be used or missing existing functionality already in the image.
It might be better to use the cURL plugin for this kind of thing...
Avi
Benjamin Pollack wrote:
I was talking to the author of a book on REST the other day, and noticed that neither HTTPClient nor HTTPSocket really seem to support REST APIs. At a bare minimum, I think you'd probably want the ability to add arbitrary headers to GET/PUT/POST (which HTTPSocket doesn't allow) and the ability to issue DELETE commands. For example, Amazon's APIs require an Authorization: header, and writing a clean WebDAV client that didn't duplicate a huge chunk of HTTPSocket functionality would be impossible at the moment. I'd be happy to submit a changeset refactoring HTTPSocket to make this more feasible, but I wanted to verify that I'm not either misunderstanding how these classes are supposed to be used or missing existing functionality already in the image.
Cheers,
--Benjamin
I keep a version of the "SWHTTPClient" library around just for this purpose. It has all of the capabilities that you described. I've used it to build several rest-ful clients. I'm not sure where I originally got it. I thought that the port was from Avi. Anyway I've modified it only slightly to make it interface in a better way with Squeak's socket timeout semantics. If anyone wants the modified version, or if this software is being maintained somewhere, I'd be happy to merge in my changes.
David
"Benjamin Pollack" benjamin.pollack@gmail.com writes:
I was talking to the author of a book on REST the other day, and noticed that neither HTTPClient nor HTTPSocket really seem to support REST APIs. At a bare minimum, I think you'd probably want the ability to add arbitrary headers to GET/PUT/POST (which HTTPSocket doesn't allow) and the ability to issue DELETE commands. For example, Amazon's APIs require an Authorization: header, and writing a clean WebDAV client that didn't duplicate a huge chunk of HTTPSocket functionality would be impossible at the moment. I'd be happy to submit a changeset refactoring HTTPSocket to make this more feasible, but I wanted to verify that I'm not either misunderstanding how these classes are supposed to be used or missing existing functionality already in the image.
HTTPSocket is really very minimal. No one that I know of has taken the time to factor out a proper HTTP client out of it.
A great start would be to make an HTTPRequest object out of all the parameters of all the methods on the class side. One for the URL, one for GET vs. PUT, one for form arguments, one for authentication info, etc.
Then you could send "retrieve" or something to a request, and get the response back.
Once to that stage, it would be really easy to add the extra control you describe, e.g. adding raw HTTP headers.
Lex
On 24 Mar 2007 20:59:42 +0100, Lex Spoon lex@lexspoon.org wrote:
HTTPSocket is really very minimal. No one that I know of has taken the time to factor out a proper HTTP client out of it.
A great start would be to make an HTTPRequest object out of all the parameters of all the methods on the class side. One for the URL, one for GET vs. PUT, one for form arguments, one for authentication info, etc.
This seems like a fun little project to do. Could you elaborate a little bit more? I'd like to try to work on this.
Thanks,
Duncan.
Duncan,
You should have a look at the class hierarchy of HttpOperation in the Passport package (it's part of the Chronos distribution, http://www.chronos-st.org).
--Alan
_____
From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Duncan Mak Sent: Sunday, March 25, 2007 11:44 AM To: The general-purpose Squeak developers list Subject: Re: Calling REST APIs from Squeak
On 24 Mar 2007 20:59:42 +0100, Lex Spoon lex@lexspoon.org wrote:
HTTPSocket is really very minimal. No one that I know of has taken the time to factor out a proper HTTP client out of it.
A great start would be to make an HTTPRequest object out of all the parameters of all the methods on the class side. One for the URL, one for GET vs. PUT, one for form arguments, one for authentication info, etc.
This seems like a fun little project to do. Could you elaborate a little bit more? I'd like to try to work on this.
Thanks,
Duncan.
squeak-dev@lists.squeakfoundation.org
-
Alan Lovejoy -
Avi Bryant -
Benjamin Pollack -
David Shaffer -
Duncan Mak -
Lex Spoon