Re: return parms in http_url_post_xml

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

> My question is around the library setup and HTTPAPI. Can I simply copy
> the /Copy routines, objects etc. that I require from LIBHTTP into my own
> (test/production)library and go from there.

Depends on how you build HTTPAPI.  There were options about whether the 
library list should be used or not.  If you answered them so that the 
library list is used for everything, then you can copy the stuff to your 
own library and it should work properly.  If not, you may have to change 
some hard-coded references to LIBHTTP.

However...

I don't recommend making your own copy of the HTTPAPI code/programs. 
This makes it significantly more difficult to upgrade HTTPAPI -- since 
you'll have to repeat the process of copying it, etc.

Instead, I recommend keeping HTTPAPI and the code you downloaded with 
HTTPAPI in the LIBHTTP library.   Put your own code that calls it into 
your own test/qa/prod libraries.

It's not any different from the operating system.  You don't copy the 
objects from OS/400 into your test/qa/prod libraries, do you?   No, you 
reference them from QSYS, and the same objects are referenced from all 
of your environments.  When you upgrade OS/400, you upgrade it for all 
environments at once.

That makes it a lot easier to upgrade HTTPAPI (or OS/400) since you can 
just delete the old library and create a new one, and you're done.

But... that's just my suggestion.  You certainly *can* copy it into your 
own libraries and test it in test/qa/prod environments, just as you 
would your own code.

> Also do I need to concern myself about security with transaction
> sending? Sorry I am new to the web service world, any help would be
> appreciated.

Doesn't matter what you're doing... you always need to concern yourself 
with security!   (That's about the only safe way to answer that 
question, heh.)

But, realistically... you need to look at the information you're sending 
and how you're sending it and make a determination.  I can't make that 
determination for you.  I don't know whether the data is encrypted in 
the transport (i.e. SSL) or encrypted at the data level.  I don't know 
what data you're sending, or how sensitive it's considered.  I don't 
know your company's business or how big of a risk you're willing to take.

However, you should understand this:  If your URL starts with 'http:', 
then HTTPAPI sends it unencrypted.  Anyone who can gain access (lawfully 
or unlawfully) to one of the routers or networks between your computer 
and the one you're exchanging information with can therefore see 
everything you're sending.  Unless you've taken your own measures to 
prevent that.  'http:' is also vulnerable to man-in-the-middle attacks, 
since there's no reliable way to determine who it's talking to.

If your URL starts with 'https:' then HTTPAPI is using SSL, which has 
safeguards.  It uses digital certificates to guard against 
man-in-the-middle attacks, and it uses encryption to protect the data 
against visibility.   Can these measures be broken?   Probably, but it's 
a lot harder than the non-SSL variant.

Are you willing to take the risks?  I can't decide that, only you can.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------