Re: PUT?

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi James,

The support you're looking for already exists in the current release 
(1.24) of HTTPAPI -- at least, to a certain extent.  (It does not exist 
at 1.23, however.)

The API I'm speaking of is http_persist_req().

In older releases (1.23 and earlier) when you called http_get_xxx or 
http_post_xxx, under the covers it went through this sequence:

1) http_persist_open
2) http_persist_get / http_persist_post
3) http_persist_close

Granted, the various http_url_get_xxx and http_url_post_xxx routines 
added functionality above/beyond the persist routines, but at their 
core, they all called these 3 persist routines.

In 1.24, I added http_persist_req() which can make either a GET, POST, 
PUT or DELETE request.  I changed http_persist_get and http_persist_post 
to call http_persist_req under the covers -- so now http_persist_req 
does all of the work, no matter whether you want to do a GET or a POST.

But, what you can also do is call this routine yourself.  Your calling 
program can do:

Pointer = http_persist_open( URL );
if (pointer = *null);
    // get http_error as normal
endif

rc = http_persist_req( 'PUT'
                      : Pointer
                      .. other parms ... );
// check error

http_persist_close( Pointer );

That would let you do a PUT request.  Change the first parameter to a 
'DELETE' if you want to do a DELETE request instead.

Now what I'm working on is making a more friendly front-end to it, 
similar to what we currently have with http_get() or http_post() (or the 
XML equivalents.)  Perhaps it'll be called http_req().

Since http_req() can do GET, POST, PUT and DELETE, and I know nobody is 
currently using http_req(), I'm trying to think of the best way to 
structure the parameters.  I don't want to have all of the same baggage 
that the http_get() and http_post() routines have... they sort of 
"evolved" that way, but since I can start fresh, I want to make it as 
intuitive as possible.  So I'm thinking about maybe an interface like this:

  D http_req        PR            10I 0
  D   method                      10a   varying const
  D   url                      32767A   varying const options(*varsize)
  D   uploadData            (whatever)
  D   contentType           (whatever)
  D   downloadData          (whatever)

I'm thinking the other stuff (user agent, timeout, soap-action, etc) can 
be specified out-of-band to keep this interface as simple as possible.

But I'm not sure exactly what to do as far as handling the different 
media types (calling the XML parser vs. writing to a stream file, vs 
returning to memory, vs callback) I want to make it as elegant/intuitive 
as possible, and I'm not sure exactly how to structure the parameters to 
do that.

So that's where I am.

On 2/6/2012 3:40 PM, James Lampert wrote:
> Scott Klement wrote:
>> Adding other HTTP methods (besides just GET and POST) has been on my
>> to-do list for awhile.
>>
>> Do you need PUT?  If so, you can help me test.  (Yay!)
>
> And DELETE, too, probably.
>
> And I'd even be willing to help with the implementation, too, if I had
> the slightest idea what to do.
>
> Regardless, I'd have to come up with a custom "drop-in compatible with
> non-SSL 1.23" version of the service program, but that's probably just
> an extension of what I've already learned how to do.
>
> Unfortunately, I've just been dropped into an urgent project in another
> area, that could tie me up all week.
>
> --
> JHHL
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------