NetTalk Central
NetTalk Web Server => Web Server - Ask For Help => Topic started by: jslarve on April 24, 2020, 12:58:21 PM
-
I have an API server where you upload an image and it returns a processed image encoded with B64.
It works fine when using SetAccept('xml') on the client. Pretty snappy. The b64 is split up into 75 character lines. Groovy.
When SetAccept('json'), it works fine, but the b64 is returned as one large string (not multi lined).
This makes it impossible for a TEXT control to view it. It just freezes up. I guess that's OK if I can't load in a TEXT control, but I'd like to be able to if possible.
2 Questions:
- Is using b64 the wrong approach for returning an image? I want to avoid saving the image on disk.
- Is there a setting to allow the B64 to be split up in the json version?
Thanks.
-
Adding a HScroll to my textbox helped with this, but I'm still interested in hearing whether the b64 can be split and still work.
Thanks
I have an API server where you upload an image and it returns a processed image encoded with B64.
It works fine when using SetAccept('xml') on the client. Pretty snappy. The b64 is split up into 75 character lines. Groovy.
When SetAccept('json'), it works fine, but the b64 is returned as one large string (not multi lined).
This makes it impossible for a TEXT control to view it. It just freezes up. I guess that's OK if I can't load in a TEXT control, but I'd like to be able to if possible.
2 Questions:
- Is using b64 the wrong approach for returning an image? I want to avoid saving the image on disk.
- Is there a setting to allow the B64 to be split up in the json version?
Thanks.
-
Speaking from pure guesswork and no knowledge, Jeff.
But I'm wondering how you're converting it in your API server prior to sending it back.
Have you tried using a String Theory object and playing with the st:nowrap property?
https://www.capesoft.com/docs/StringTheory3/StringTheory.htm#stBase64Encode
It would appear that its default is to do the wrapping. Which is apparently the RFC default.
Can you use debug code in your service and see what's being done differently between the XML and JSON outputs?
Yours in ignorance,
Jane
-
Hi Jane -
My StringTheory object does the Base64Encode() using the default parameters inside the ServiceMethod ROUTINE (which splits it up into 75 character lines).
The StringTheory object is set as a return.
With XML, it leaves the contents split up.
With JSON, it strips out the CRLF.
Now that I know that the horizontal scroll helps, it's not that big of a deal. Just trying to understand if that's intentional.
I'm wondering if I should prepend the image with "data:image/png;base64," or if I'd be better off with plain ol' bas64 or if there's a better method of delivery.
Thanks for your response.
Speaking from pure guesswork and no knowledge, Jeff.
But I'm wondering how you're converting it in your API server prior to sending it back.
Have you tried using a String Theory object and playing with the st:nowrap property?
https://www.capesoft.com/docs/StringTheory3/StringTheory.htm#stBase64Encode
It would appear that its default is to do the wrapping. Which is apparently the RFC default.
Can you use debug code in your service and see what's being done differently between the XML and JSON outputs?
Yours in ignorance,
Jane
-
Well, as another WAG, Jeff, maybe you could manually tweak the code and Append or SetValue using json:Json to tell JFiles that the data is already JSON-encoded?
-
Hi Jane -
Thanks for your help. I think it works okay without me messing with that. Apparently json doesn't support multi-line data very well, so it's probably best to serve it as one big string.
I guess my real question is: What is the best way to serve up an image?
Instead of XML or JSON, is it possible to simply return an image or other binary file?
either as:
'data:image/png;base64,' & MyBase64EncodedPngImageStringTheory.GetValue()
or:
MyBinaryDataStringTheory.GetValue()
I attached the current XML result.
Wondering if the stuff inside the "<DecodedImage>" tag could be the result itself.
Thank you.
-
Hi Jeff,
>> Apparently json doesn't support multi-line data very well,
it supports it perfectly. But JSON encoding requires <13> to be encoded as \r and <10> as \l.
So really all you need to do is jsonDecode it before sending it to your text control.
>> I guess my real question is: What is the best way to serve up an image?
to whom? A browser? An API Client?
Generally speaking base64 is the best way to send data back, but context is everything.
>> Wondering if the stuff inside the "<DecodedImage>" tag could be the result itself.
not if the result is returned as XML or JSON since neither of those are binary formats. In both those cases base64 of teh binary is the best option.
cheers
Bruce
-
>> So really all you need to do is jsonDecode it before sending it to your text control.
Okay. Thank you.
>> to whom? A browser? An API Client?
Generally speaking base64 is the best way to send data back, but context is everything.
If, say, I wanted to have the quickest route to providing an image src=https://MyApi.com?YadaYada on a web page.
But since I need to send an image too, I guess that's not so simple to do when I need to POST.
In cases where I am able to do a GET, it would be cool if I could just return the image (not in XML or JSON) for direct use on the page.
>>>> Wondering if the stuff inside the "<DecodedImage>" tag could be the result itself.
>>not if the result is returned as XML or JSON since neither of those are binary formats. In both those cases base64 of teh binary is the best option.
Was wondering if I could have the option of JUST returning the image. Not inside XML or JSON. I am still pretty noob with NetTalk.
I'm talking about something like they're talking about on this page. https://stackoverflow.com/questions/39177576/how-to-to-return-an-image-with-web-api-get-method
Thanks for getting back to me Bruce.
Hi Jeff,
>> Apparently json doesn't support multi-line data very well,
it supports it perfectly. But JSON encoding requires <13> to be encoded as \r and <10> as \l.
So really all you need to do is jsonDecode it before sending it to your text control.
>> I guess my real question is: What is the best way to serve up an image?
to whom? A browser? An API Client?
Generally speaking base64 is the best way to send data back, but context is everything.
>> Wondering if the stuff inside the "<DecodedImage>" tag could be the result itself.
not if the result is returned as XML or JSON since neither of those are binary formats. In both those cases base64 of teh binary is the best option.
cheers
Bruce
-
>> say, I wanted to have the quickest route to providing an image src=https://MyApi.com?YadaYada
they they should simply use a URL.
src="https://myapi.com/whatever.jpg"
Assuming that whatever.jpg is in the web folder.
or say
src="https://myapi.com/images/whatever.jpg"
if it is in the \web\images folder.
>> In cases where I am able to do a GET, it would be cool if I could just return the image (not in XML or JSON) for direct use on the page.
same URL - just do a simple GET.
Cheers
Bruce
-
Hi Bruce -
Maybe my question is too simple.
I'm asking what _I_ should on my NetTalk server do so that it's possible that THEY can do the simple GET to retrieve the image. :-)
I want my own server to return the image (or other kinds of binary files), but I am looking for advice on how to accomplish that with NetTalk. I am currently returning JSON or XML, but I want to know the NetTalk way to to return a non-static image (that I generate) without encoding it into JSON or XML.
Does that make any sense?
Thank you.
>> say, I wanted to have the quickest route to providing an image src=https://MyApi.com?YadaYada
they they should simply use a URL.
src="https://myapi.com/whatever.jpg"
Assuming that whatever.jpg is in the web folder.
or say
src="https://myapi.com/images/whatever.jpg"
if it is in the \web\images folder.
>> In cases where I am able to do a GET, it would be cool if I could just return the image (not in XML or JSON) for direct use on the page.
same URL - just do a simple GET.
Cheers
Bruce
-
Jeff,
Would it be unacceptable to create your image, save the result to a temporary file on the web server, and then serve that file?
If you begin the filename with $$$ then the file will be deleted from the server after it has been served once. That's also the typical approach for creating and serving PDF reports. (Search for "$$$" on this page: https://www.capesoft.com/docs/NetTalk11/NetWebReports.htm)
edit: never mind. you're talking API.... I don't know if the $$$ trick works there.
-
Hi Jane -
Interesting. Maybe that would work for me. Thank you.
I'd still like to know if it would be possible to do it the other way, but the $$$ might do.
I appreciate your help.
Jeff,
Would it be unacceptable to create your image, save the result to a temporary file on the web server, and then serve that file?
If you begin the filename with $$$ then the file will be deleted from the server after it has been served once. That's also the typical approach for creating and serving PDF reports. (Search for "$$$" on this page: https://www.capesoft.com/docs/NetTalk11/NetWebReports.htm)
Jane
-
Hi Jeff,
I think you are over-thinking this a bit :)
>> Maybe my question is too simple.
>> I'm asking what _I_ should on my NetTalk server do so that it's possible that THEY can do the simple GET to retrieve the image. :-)
The short answer is "nothing for you to do - it already does that".
The long answer adds the sentence ".. as long as the image is in the web folder,or sub folder.".
In other words, files in the web (or sub) folders can be served if the user just enters the name.
There's nothing for you do to - the server is a server, and this is what it serves.
There's no "API" involved here - serving files is what the web server _does_.
I think you've gone down a very (very) common thought problem though. Typically we start with serving static files, then graduate to Web API's then Web Apps (then Mobile apps). Along the way we can start overthinking a situation - especially (I've noticed) serving static files.
_Of course_ it can then more complicated (like serving from a BLOB field etc), but at it's root static files in the web folder are just "served".
cheers
Bruce
-
I was trying to avoid writing any files to disk. I'm already doing that in the returned XML/JSON. But I just wanted to serve the image. Thanks anyway.
Hi Jeff,
I think you are over-thinking this a bit :)
>> Maybe my question is too simple.
>> I'm asking what _I_ should on my NetTalk server do so that it's possible that THEY can do the simple GET to retrieve the image. :-)
The short answer is "nothing for you to do - it already does that".
The long answer adds the sentence ".. as long as the image is in the web folder,or sub folder.".
In other words, files in the web (or sub) folders can be served if the user just enters the name.
There's nothing for you do to - the server is a server, and this is what it serves.
There's no "API" involved here - serving files is what the web server _does_.
I think you've gone down a very (very) common thought problem though. Typically we start with serving static files, then graduate to Web API's then Web Apps (then Mobile apps). Along the way we can start overthinking a situation - especially (I've noticed) serving static files.
_Of course_ it can then more complicated (like serving from a BLOB field etc), but at it's root static files in the web folder are just "served".
cheers
Bruce
-
so, if it's not on disk, where is it?
cheers
Bruce
-
A StringTheory object.
I'll play with the $$$ file idea. Maybe that will be good enough. Thanks Bruce.
so, if it's not on disk, where is it?
cheers
Bruce
-
Where did the stringtheory object come from?
Are you drawing something on the fly?
From a blob?
-
Hi Bruce -
I am generating the images on the fly.
But saving to disk will probably work out best, with the "$$$" as Jane suggested.
Haven't had a chance to test it out yet, but will hopefully get some time next week.
Thank you.
Where did the stringtheory object come from?
Are you drawing something on the fly?
From a blob?
-
>>But saving to disk will probably work out best, with the "$$$" as Jane suggested.
I concur