[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HTTP Bad Request Posting JSON
Scott,
Thanks for this I will give it a try.
What I did is I looked at one of your articles and you mentioned that
the brackets and square brackets were treated differently when sending
data and these are important codes for JSON, and you had an example in
an RPG program of how to define these in the D Specs (see below)
D LeftBracket C Const(%UCS2('['))
D RightBracket C Const(%UCS2(']'))
D LeftBrace C Const(%UCS2('{'))
D RightBrace C Const(%UCS2('}'))
Then you mentioned that all you had to do was normal string building in
RPGLE. But it wouldn't let me do the string building because
LeftBracket and the text in quotes were of different data types so it
failed at compile time. So I assumed that if I use the BIF(%UCS2) to
build all of the MyJSON variable so not mixing different data types and
see what this would give me. It gave me the result I wanted in
the httpapi_debug.txt and when I ran the program it was successful.
Now you say that this is actually UTF-16 instead of UTF-8 I presume
this is the difference between single and double byte characters? I am
not sure if this is a problem? If it is it would be for the API that is
consuming the web service on the server side.
Do you think I am ok with what I have done or the better solution
is http_setCCSIDs(1208:37). I have a slight issue in that here we are
using a mixture of CCSID's of 37, 285, and 65535. So if I need to
translate I am assuming that this is based on the CCSID of the job that
is running at the time. So I guess that I would have to retrieve CCSID
of the job at run time and then call http_setCCSIDs(1208:JOBCCSID)
I hope this makes sense
Regards
Barry
Barry Giles email - barrygiles_uk@xxxxxxxxxxx
__________________________________________________________________
From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, 11 October 2016, 23:11
Subject: Re: HTTP Bad Request Posting JSON
Barry,
http_setCCSIDs(1208:37) means "translate from 37 to 1208 when sending"
(or vice-versa when receiving)
But you had:
https_setCCSIDs(1208:1208) which means "translate from 1208 to 1208"
(same as "do not translate")
I don't understand how this relates to the %UCS2() BIF, which is not
capable of translating to/from 1208. (%UCS2 supports CCSID 13488 which
is UCS-2 or CCSID 1200 which is UTF-16. It does not and cannot support
CCSID 1208 which is UTF-8).
-SK
On 10/10/2016 3:39 AM, Barry Giles wrote:
> Scott,
> Our CCSID is set to 37 or 285.
> After reading everything I worked out that the JSON data had to be
in
> UTF-8. I am assuming that your HTTPIAPI doesn't translate from
EBCDIC
> to UTF-8 but probably the YAJL procedures would translate to
UTF-8.
> As I don't want to use the YAJL procedures just yet for my POC; I
> wanted to hand craft it myself just to understand how everything
works.
> I wanted to translate the JSON data to UTF-8 and I thought that is
what
> your procedure HTTP_setCCSIDs achieves. It looks as though that
didn't
> give my the results I wanted so I just translated it myself using
> standard RPG BIF %UCS2 and now my program works perfect.
> Thanks very much for your response much appreciated as usual.
> Below is my working code.
> // Build up the JSON Object and convert to UTF-8.
>
> myJSON = LeftBrace +
>
> %UCS2(' "firstname": "Zorro"')
>
> + Comma + %UCS2(' "lastname": "Gutierrez"')
>
> + Comma + %UCS2(' "email":
"[1]rgutierrez@xxxxxxxxxxxxx"')
>
> + Comma + %UCS2(' "telephone": "66-(361)753-8689"')
>
> + Comma + %UCS2(' "storeid": 6')
>
> + Comma + %UCS2(' "PTEId": null')
>
> + Comma + %UCS2(' "travelInfo": "Nulla temptus."' )
>
> + Comma + %UCS2('"type": "by phone"')
>
> + Comma + %UCS2(' "requestDate": "2016-09-22 10:58:05"')
>
> + Comma + %UCS2(' "date": "2016-09-01"')
>
> + Comma + %UCS2(' "time": "19:20"')
>
> + Comma
>
> + RightBrace;
>
>
>
> Kind Regards
> Barry
>
> Barry Giles email - [2]barrygiles_uk@xxxxxxxxxxx
>
__________________________________________________________________
>
> From: Scott Klement <[3]sk@xxxxxxxxxxxxxxxx>
> To: HTTPAPI and FTPAPI Projects <[4]ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Friday, 7 October 2016, 23:26
> Subject: Re: HTTP Bad Request Posting JSON
> Barry,
> You are coding HTTP_setCCSIDs(1208:1208) which means that the data
in
> your RPG program is already in CCSID 1208. But, the code that you
> posted shows that data in EBCDIC.
> As a result, it is not translating the data at all. (Since you
say you
> want it in 1208, and it's already in 1208, no translation takes
> place). Since the data isn't really in 1208, its sending the raw
> EBCDIC values, and the web service doesn't understand them.
> Can you explain why you are setting http_setCCSIDs() in this
manner?
> On 10/4/2016 11:20 AM, Barry Giles wrote:
> > I have been using Scott's HTTPAPI for many years now very
> successfully
> > but only using XML.
> > I have built my own front end for building XML HTTP Requests
as
> there
> > hasn't been anything out there on the market and I use
Scott's
> HTTPAPI
> > to send the requests and response to the request.
> > This is in production with 5 separate suppliers using
multiple
> requests
> > per supplier and works awesome and means that we can
basically
> build
> > requests and respond to them via XML tags in under 1 day for
any
> type
> > of request and response thanks to Scott and my methodology.
(If
> anyone
> > wants my front end XML builder they are welcome to all the
source
> code
> > and objects and powerpoint presentation explaining how it
works ).
> It
> > is screen and file driven meaning that you have to enter in
the
> XML
> > tags and sequence and define the type and in each request
program
> call
> > the BUILDREQUEST procedure and uses call back same as Scott's
> HTTPAPI.
> > It takes away the pain of XML begin and end TAG building and
is
> very
> > flexible and easy to amend.
> > We are stuck on the IBMi at V5R4.
> > To this end I now need to do the same but using JSON. As I
have
> seen
> > there are JSON libraries out there YAJL that perform the
building
> and
> > parsing of JSON data but no standard methodology to Build /
Send/
> > Respond. So I am in the process of building that methodology
using
> > Scott's HTTPAPI. So what I am trying to achieve? Well I know
that
> > Scott's software which is a black box solution will do all
the
> > Communications for me this means that you pass in a URL and
the
> request
> > data and it is clever enough to basically take all the
information
> we
> > provide and will strip it down to the lowest level and take
care
> of all
> > the Sockets programming removing the need for us to worry
about
> it. It
> > will then transmit the data over the internet and return the
> response.
> > In Scott's methodology for Posting XML data he uses a
procedure
> > INCOMING to process the response that come back in 8192
chunks of
> data.
> > Now there isn't any POSTJSON equivalent so I have to build
one.
> > 1 - Build the JSON Request data (fields and data I will use
the
> > procedures in YAJL)
> > 2 - Post the request to the 3rd party supplier (I will use
> > Scott's http_url_post)
> > 3- Deal with the response. (I will use a combination of
Scott's
> return
> > data in the IFS and YAJL)
> > Now I am struggling with my POC as I have written a very
simple
> RPG
> > program (not using YAJL yet) but Scott's http_url_post is
failing
> with
> > the request data it is transmitting. Now I believe that when
Scott
> > sends the actual data it has been translated from EBCDIC to
ASCII
> I
> > think using BASE64. When I post using XML then when it writes
the
> debug
> > data to /tmp/httpapi_debug.txt this is readable on the IBMi
so i
> think
> > this is pre-translated. But when I do the same for JSON data
in
> > the /tmp/httpapi_debug.txt it is NOT readable on the IBMi so
I am
> > guessing that it has been translated prior to writing
> > to /tmp/httpapi_debug.txt. Now this is strange because it
doesn't
> > matter if it's XML or JSON as it is just data and these are
just
> data
> > formats to make it more human readable.
> > So does anyone have any idea why JSON data that is posted
> > gives HTTP/1.1 400 Bad Request. I know that the data is ok
because
> I do
> > the same on google POSTMAN and it works fine.
> > I would appreciate some help from someone that has already
got
> JSON
> > data sent ok using Scott's HTTPAPI procedures, and if
possible
> some
> > working RPG source code.
> > My RPG
> > d GlobalError s n
> > d rc s 10I 0
> > d wwErrorNo s 10I 0
> > d wwHttpErr c const('HTTP Comms')
> > d tmpfile s 50a varying
> > d Service s 256a
> > d ClientID s 100a
> > d AuthCode s 256a
> > d Password s 50a
> > d jsonAddr s 65535A varying
> > d jsonSize s 10I 0
> > // Setup HTTP Logging of requests going out and in
> >
> > HTTP_debug(*on);
> >
> > HTTP_SetCCSIDs(1208:1208);
> >
> > HTTP_SetFileCCSID(1208);
> >
> >
> >
> > service =
> '[1][5]https://115.112.132.136/KuoniService/api/appointment/save';
> >
> > clientid = 'xxxxx';
> >
> > password = 'xxxxxxx';
> >
> >
http_setauth(HTTP_AUTH_BASIC:%trim(clientid):%trim(password));
> >
> >
> >
> > // Create a Temporary file in the IFS to contain Response
> >
> > tmpfile = http_tempfile();
> >
> > jsonSize = %Size(jsonAddr);
> >
> > // Build up the JSON Object
> > jsonAddr = '{' +
> > ' "firstname": "Zorro",'
> > + ' "lastname": "Gutierrez", '
> > + ' "email": "[2][6]rgutierrez@xxxxxxxxxxxxx", '
> > + ' "telephone": "66-(361)753-8689", '
> > + ' "storeid": 6, '
> > + ' "PTEId": null, '
> > + ' "travelInfo": "Nulla temptus.", '
> > + ' "type": "by phone", '
> > + ' "requestDate": "2016-09-22 10:58:05", '
> > + ' "date": "2016-09-01", '
> > + ' "time": "19:20" '
> > + '}';
> > // Perform HTTP request and response
> >
> > rc = http_url_post( Service
> >
> > : %addr(jsonAddr)
> >
> > : %len(jsonAddr)
> >
> > : tmpfile
> >
> > : HTTP_TIMEOUT
> >
> > : HTTP_USERAGENT
> >
> > : 'application/json');
> >
> >
> >
> > The error
> > Host: 115.112.132.136
> >
> > User-Agent: http-api/1.24
> >
> > Content-Type: application/json
> >
> > Content-Length: 299
> >
> > Authorization: Basic (removed as this can be translated from
> BASE64
> > back to char easily hence showing the user and password)
> >
> >
> >
> >
> >
> >
> > senddoc(): entered
> >
> > +�@@ ¢£ z@ é k@@ ¢£ z@ �¤£ ©
k@@@
> > z@ ¤£ ©| ¢£K k@@@@ £ z@
> > öö`Móöñ]÷õó`øöøù k@@@@
> > recvresp(): entered
> >
> > HTTP/1.1 400 Bad Request
> >
> > Cache-Control: no-cache
> >
> > Pragma: no-cache
> >
> > Content-Type: application/json; charset=utf-8
> >
> > Expires: -1
> >
> > Server: Microsoft-IIS/7.5
> >
> > X-AspNet-Version: 4.0.30319
> >
> > Barry Giles
> >
> > Barry Giles email - [3][7]barrygiles_uk@xxxxxxxxxxx
> >
> >
> >
> >
>
-----------------------------------------------------------------------
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > [4][8]http://www.scottklement.com/mailman/listinfo/ftpapi
> >
>
-----------------------------------------------------------------------
>
-----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> [5][9]http://www.scottklement.com/mailman/listinfo/ftpapi
>
-----------------------------------------------------------------------
>
> References
>
> 1. [10]https://115.112.132.136/KuoniService/api/appointment/save';
> 2. mailto:[11]rgutierrez@xxxxxxxxxxxxx
> 3. mailto:[12]barrygiles_uk@xxxxxxxxxxx
> 4. [13]http://www.scottklement.com/mailman/listinfo/ftpapi
> 5. [14]http://www.scottklement.com/mailman/listinfo/ftpapi
>
>
>
>
-----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> [15]http://www.scottklement.com/mailman/listinfo/ftpapi
>
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
[16]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References
1. mailto:rgutierrez@xxxxxxxxxxxxx
2. mailto:barrygiles_uk@xxxxxxxxxxx
3. mailto:sk@xxxxxxxxxxxxxxxx
4. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
5. https://115.112.132.136/KuoniService/api/appointment/save';
6. mailto:rgutierrez@xxxxxxxxxxxxx
7. mailto:barrygiles_uk@xxxxxxxxxxx
8. http://www.scottklement.com/mailman/listinfo/ftpapi
9. http://www.scottklement.com/mailman/listinfo/ftpapi
10. https://115.112.132.136/KuoniService/api/appointment/save';
11. mailto:rgutierrez@xxxxxxxxxxxxx
12. mailto:barrygiles_uk@xxxxxxxxxxx
13. http://www.scottklement.com/mailman/listinfo/ftpapi
14. http://www.scottklement.com/mailman/listinfo/ftpapi
15. http://www.scottklement.com/mailman/listinfo/ftpapi
16. 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
-----------------------------------------------------------------------