• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

Create "Temp" File to get around missing API functionlity?

 
Bartender
Posts: 1815
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

I am using an API that expects a disk file path to read a file for its action.

However, this test standalone code needs to work in a REST service. But, there doesn't seem to be any overloaded methods to use a file stream.

I'm wondering therefore how best to work around this issue.

I thought that perhaps, in the REST service I could receive the file contents via Base64 Encoding (as you would normally expect transferring binary data), then create a TEMPorary file and use that disk path to the temp file for the API.

This approach sounds kludgy to me, but perhaps it's the best way to handle a situation like this?

Would appreciate any suggestions.

Thanks,

-- mike
 
Saloon Keeper
Posts: 23774
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm really not clear on what you want, but you cannot use a web service (ReST or otherwise) to read (or write) a file from a client machine to a server machine.

Webservers are not fileservers. They use different protocols. And you should be glad. If a webserver had the ability to rummage around in your local desktop filesystem, the results would be very, very ugly.

Now obviously you can up/download a file from a webserver, but that's a different process. For one thing, the actual interaction with the client's filesystem is done totally under client control. For another, it isn't actually the client's file that's being operated on. Instead, it's a copy of the data in the file. The distinction is critical, since it means that first of all, you cannot use standard filesystem I/O services (open/close/read/write) and secondly that a specific mechanism has to be used.

For uploading a file, you have two common opions. For browser-based uploads, you'd define a multi-part HTML FORM with a file upload control to manage the process. The client's SUBMIT operation would then build an HTTP service request and include the file data in a MIME-encapsulated fragment of the SUBMIT data package.

For ReST, you may not have a web page. But what you can do is append the file data to an HTTP POST request.
 
Mike London
Bartender
Posts: 1815
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry for the confusion. I'll try to clear this up.

We want to use an API library inside a web service.

Currently, however, that API only has a method to read a file using a disk path. Obviously, that method isn't right for a REST service, which should, instead, get a Base64Encoded file stream.

So, my question is, since the API doesn't have a method to handle a Base64Encoded file stream, how to best work around that.

Here's what I'm asking about:

1. Receive the Base64Encoded file data in POST method. (we would make the calling program send the Base64 stream)
2. Convert to "Temporary" path. (we would do this in the POST logic)
3. Use that Temporary path for the API that only works with paths, not file streams.

Is this approach the best under the circumstances?

Thanks,

-- mike
 
Marshal
Posts: 3572
505
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike London wrote:Currently, however, that API only has a method to read a file using a disk path.


When you say path, do you mean java.nio.file.Path, or a String with a path to the file (like "/home/app/in.dat")?
 
Mike London
Bartender
Posts: 1815
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A regular disk path (as in your second example).

Thanks
 
Tim Holloway
Saloon Keeper
Posts: 23774
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, I'm still confused. Is the original API supposed to be given a file path for a file living on the webapp server? Because any file paths on the client are moot - the webapp server cannot use them since it cannot open files on the client (repeating myself here).
 
Tim Holloway
Saloon Keeper
Posts: 23774
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OR...

Is it that you;ve got a currenlt non-web API that you want to convert to an equivalent ReST webapp API?

If the original API accepted a file path that it could open and read, then yes, a ReST POST of the contents of that file would work. You probably won't even need Base64 encoding thses days. Base64 is mainly to support bouncing stuff around between multiple machines which might not all have the same byte organization or size.

So you could simply build the request on the fly and no local (client-side) tempfile needed, and even Byte64 encode on the fly.

On the server side, it's your option to ignore the uploaded data stream, eat it as it comes in, or store it to a local disk file.

Downloading, of course requires you to set appropriate outbound HTTP headers, including Content-Type abd leaves it up to the client as to what to so with the incoming data stream.

Since this only a copy of the file contents, updating and deleting by the server are not possible.
 
Mike London
Bartender
Posts: 1815
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's an API/library that wasn't built with REST in mind I guess.

Since the REST service won't be on the same server as the client, a path to a file would not work.

I'm going to go with the temp file idea for now at least until I can find a better solution.

Thanks,
 
Tim Holloway
Saloon Keeper
Posts: 23774
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A temporary file on the client is no different than a permanent file on the client. The webapp server cannot deal with either one, nor even tell one from the other.

All you can do is copy the file contents to the server, and on the server side, as I said, dumping the data into a temporary file is only one of several options.
 
Master Rancher
Posts: 3903
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mike - if I understand correctly, you're not talking about any file necessarily being on the client; the client is sending its data via an http POST or PUT.  But on the server, you need to use some 3rd party library that expects an actual file, because the author didn't know any better.  Assuming you can't find a better API, then yes, you can just create a temp file; that seems best, distasteful as it is.  Note that you can use Files.createTempFile() to create it in an appropriate location that is likely to be deleted later.  Though I would want to delete it myself once I'm done with it, so it doesn't build up wasted space.
 
Tim Holloway
Saloon Keeper
Posts: 23774
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah. If you're using the original API on the server and it needs a file path, you need something that has a filesystem path. Whether that something is temporary or permanent is immaterial. It can be a file on hard disk or RAMdisk. And so forth. Just create the file and copy data from the request input.

Now specifically, temporary webapp files supported by the java.io.File infrastructure of the JVM. Which, in turn has an assumed temporary directory. For Unix-style OS's, that would ordinarily be the /tmp directory, but Tomcat, for example, overrides that to be TOMCAT_HOME/temp* and that, in turn can be overridden via the environment variable CATALINA_TMPDIR.

Note that Java tempfile functionality also has the ability for you to create a tempfile that's deleted automatically after use. That can help keep things tidy. For more info, check the JavaDocs.

---
* more precisely, $CATALINA_BASE/temp
 
Sheriff
Posts: 22211
117
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Note that Java tempfile functionality also has the ability for you to create a tempfile that's deleted automatically after use. That can help keep things tidy. For more info, check the JavaDocs.


If you're talking about File.deleteOnExit(), that's going to be pretty useless on a web server. It doesn't exit as often as a CLI or UI application does - usually, it doesn't exit at all until you do an upgrade.

StandardOpenOption, used with Files.newInputStream, Files.newOutputStream, etc. has option DELETE_ON_CLOSE. However, since the API gets the path to the file as a string, Mike's not opening the file himself, so that's also not an option.

I'd probably use a try-finally block: create a temp file, pass its path to the API, finally delete the file.
 
Tim Holloway
Saloon Keeper
Posts: 23774
161
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:

Tim Holloway wrote:Note that Java tempfile functionality also has the ability for you to create a tempfile that's deleted automatically after use. That can help keep things tidy. For more info, check the JavaDocs.


If you're talking about File.deleteOnExit(), that's going to be pretty useless on a web server. It doesn't exit as often as a CLI or UI application does - usually, it doesn't exit at all until you do an upgrade.



I'd forgotten about that. Then again the last time I used it, I was in a shop where it was considered routine to restart the webapp server almost daily because to them, spending the time to develop webapps that didn't corrode as they executed wasn't considered "productive". An upgrade isn't required. Just a clean shutdown of the JVM. Sometimes we even got one!  

A try/finally/delete is certainly good for stuff that can be discarded immediately after the API call, though.
 
Get out of my mind! Look! A tiny ad!
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic