Extra space at JSON string

[marmota]

Hi!

We have Web API that provides with JSON string - IRD requests JSON with Web Service.

First when we tested the strategy we used fake API - just static html page with static JSON string - everything went OK but once we replaced fake with original API for some reason IRD started to get extra space before JSON string. I tried to copypaste what API returns - it's same JSON string but IRD sees extra space in front. Because of that IRD starts accepting result as a string not a LIST with JSON.

So I somehow need to delete extra space in front of string and deliver it to LIST variable as JSON.

Well, we worked on an option:
- String variable gets JSON
- Int variable gets string length
- LIST variable gets String starting from 1 (not 0) to length and transfroms it ti JSON with KVListFromJSONEx[String, 0]

It works. But I believe thewre should be some more efficient option. Any ideas?

P.S. Regarding KVListFromJSONEx - I found this function here at sggu - but no description at any Genesys doc (even Google doesn't know). Is it a kind of old-fashion function? Is there any replacement fot that?

[hsujdik]

Maybe the content encoding is different for the responses? (It's just a guess, but it would not hurt to double check that )

[cavagnaro]

About the KVListFromJSONEx, seems Genesys, as usual, doesn't like to document everything inside the solution, so this another easter egg on it.
There is a file from where you can get the functions available, guess you already read about it

[marmota]

Hi all! Thanks for answers!

Question about general architecture at IRD:
what do you think is better approach - parse such JSON/String/List etc. staff with IRD functions or better with JS (included at IRD as macros)?

[cavagnaro]

Actually...if you are going into JSON/REST etc...My personal recommendation is to think to move to ORS/Composer...It is just native and you can do much much more handling/control.
IRD is closed box, it is excellent for Routing/GUI but...the lack of native HTTP layer and flexible development (as web world demands) is just a good valid reason to move to ORS.


If you don't use much JSON/REST/Web, then stick with IRD, solid, stable, does a great job and is not too complex

[terry]

As far as I know function KVListFromJSON(Ex) correctly translates JSON string do they have spaces ahead or not, there is no need to delete spaces manually.
Relatively recent URSes also correctly perform translation on assigning JSON strings to LIST variable no matter do they start with spaces or not.