New API: Server and FileSystem

Christoph Hart

Hi everybody,

I've spend the last days writing the API for communicating with a server and I also added some API functions to access the file system. You can now:

call URLs and get a response as JSON object
download files
let the end user browse for files
get a directory list
write / load files (with optional Blowfish encryption)
more stuff (read the API for a full feature list)

The docs have been updated, so you can read these for a full reference:

Let me know if something is not working like it's supposed to or if there is a missing function for your use-case.

ustk

@Christoph-Hart Just seen the commit

Dan Korneff

d.healey

@Christoph-Hart said in New API: Server and FileSystem:

You can now:

call URLs and get a response as JSON object
download files
let the end user browse for files
get a directory list
write / load files (with optional Blowfish encryption)
more stuff (read the API for a full feature list)

The docs have been updated, so you can read these for a full reference:

FileSystem API
File API
Server API

Excellento!

@Christoph-Hart I saw you merged Scriptnode into the develop branch of my fork (which befuddled me!) does that mean the develop branch is also now merged into your scriptnode branch?

ustk

@Christoph-Hart I am currently removing (poor) server and file additions I've made these last days.
Although I also have a delete file method:

bool ScriptingApi::Engine::deleteFile(String fileName)
{
	File f;

	if (File::isAbsolutePath(fileName))
		f = File(fileName);
	else
		f = File(GET_PROJECT_HANDLER(getProcessor()).getSubDirectory(ProjectHandler::SubDirectories::UserPresets).getChildFile(fileName));

	if (f.existsAsFile())
		return f.deleteFile();

	return false;
}

Maybe you want to add it to the File API so I can also remove mine?

Christoph Hart

@d-healey Actually I was just checking whether there are any merge conflicts, but I need to get the CLAs from all contributors before I can merge your branch. The real task will be merging the new SNEX code...

@ustk sure, I‘ll add it. I‘m a bit hesitant with the delete method because it‘s not undoable...

d.healey

@Christoph-Hart said in New API: Server and FileSystem:

I need to get the CLAs from all contributors before I can merge your branch.

Just me, @ustk, and @Levitanus I think.

ustk

@Christoph-Hart I tested the server with no success...

This:

// Prepare the parameters
local parameters =
{
    "request":      requestType,
    "email":        emailLbl.get("text"),
    "serial_key":   serialLbl.get("text"),
    "product_id":   productId,
    "instance":     instance
};

// Make the call
Server.callWithGET(SerialNumbersAPI, parameters, function(status, response)    // SerialNumbersAPI is my sub...
{
    Console.print(status);
    Console.print(trace(response));
});

Throws that

Interface:! Expected '{' or '[': "1"
Interface: 500
Interface: {
  "error": "Expected '{' or '[': \"1\""
}

It shouldn't be because of the baseURL, subURL, or parameters because it worked before with my API...

Christoph Hart

Do you return a plain text? Because it expects JSON data

ustk

@Christoph-Hart What do you mean? the response is an object:

Server.callWithGET(SerialNumbersAPI, parameters, function(status, response)
    {
        Console.print(status);
        Console.print(response);
    });

Interface:! Expected '{' or '[': "1"
Interface: 500
Interface: Object 0x423cc0

ustk

And:

    Server.callWithGET(SerialNumbersAPI, parameters, function(status, response)
    {
        
    });

gives

Interface:! Expected '{' or '[': "1"

Christoph Hart

Well the error message is wrapped in an object, but your actual server response throws a JSON parsing error.

ustk

@Christoph-Hart Which means?
Are the parameters not good? it all strings

ustk

@Christoph-Hart
Here's my habitual call
https://www.studio427audio.com/?wc-api=serial-numbers-api&request=check&...

here's what I set

Server.setBaseURL("https://www.studio427audio.com");
const var SerialNumbersAPI = "?wc-api=serial-numbers-api";    // subURL

Christoph Hart

That's not the sub-URL these are the GET arguments. Your sub URL is empty if you call the domain directly (haven't checked whether this works though, in my experience I've always called a sub URL). The parameter object should be

const var p =
{
    "wc-api": "serial-numbers-api",
    "request": "check"
};

Server.setBaseURL("https://www.studio427audio.com");
Server.callWithGET("/", p, function(status, response)
{

});

But what does the server return? If it's just a plain old text, it won't work so you need to make sure your server returns a JSON file.

ustk

@Christoph-Hart I noticed in your example, the call adds a question mark at the end of the subURL.
I don't know if it's added or not to my url, but I know I shouldn't have one...

ustk

@Christoph-Hart I see! testing...

Christoph Hart

This works here:

Content.makeFrontInterface(600, 500);

const var p =
{
    "wc-api": "serial-numbers-api",
    "request": "check"
};

reg r;

Server.setBaseURL("https://www.studio427audio.com");
Server.callWithGET("/", p, function(status, response)
{
    r = response;
});

If you check r in the script watch table, it contains

ustk

@Christoph-Hart Yeah! Working! :)
I didn't know the api is par of GET arguments, though it was the sub...
It works like a charm! Thanks!

Christoph Hart

Yes, the GET arguments will be embedded into the URL and POST data will be sent along with it. If your server supports it I'd recommend using POST data for sending authentification information as the other one is visible throughout the communication (which makes your SSL certificate pointless).

New API: Server and FileSystem

11

1.8k

10.3k

90.0k