Bug report

Describe the bug

Bad request error while fetching all the files within a bucket.

To Reproduce

After fetching the buckets successfully, the list method returns a bad request.

let client = SupabaseClient(supabaseUrl: "{ base url }", supabaseKey: "{ key }")

client.storage.listBuckets { result in
    switch result {
        case .success(let buckets):
            guard let bucket = buckets.first else { return }
            let file = client.storage.from(id: bucket.id)
            
            file.list { fileResult in
                switch fileResult {
                    case .success(let objects):
                        print(objects)
                    case .failure(let error):
                        print(error)
                }
            }
        case .failure(let error):
            print(error)
    }
}

Expected behaviour

After forking the package and printing the data, I found that the body is missing the prefix parameter -

body should have required property 'prefix'

Adding the prefix parameter worked, and it returned the files. However, there's no mention of the prefix in the JS docs.

What kind of change does this PR introduce?

• Adds a StorageApiConfig struct with the public properties
  • url
  • headers
• Modifies StorageApi, StorageBucketApi and SupabaaseStorageClient to use the new config object.
• Adds an initializer to each above class to initialize directly with a config object.

What is the current behavior?

Config variables (url, headers) aren't available to a public API. This leads to problems when dealing with auth changes and other changing things that may need to change headers after initalization.

What is the new behavior?

Config can be changed in various ways

// Add an authorization header
client.config.headers["Authorization"] = "Bearer: 1234"

// Change the base url
client.config.url = "app.supabase.io"

// Remove an authorization header
client.config.headers["Authorization"] = nil

// Initialize a client using a config object
let config = StorageApiConfig(url: "app.supabase.io", headers: [:])

let client = SupabaseStorageClient(config)

Other notes

This is also a modification related to the changes on this PR on postgrest-swift.

What kind of change does this PR introduce?

Bug fix, feature, docs update, ...

What is the current behavior?

• fetch return-type dependant on response
• data is then decoded with JSONSerialization and instances created manually

What is the new behavior?

• fetch returns response data directly, but will still attempt to decode and throw an error if the status code is not 2XX
• data is decoded using JSONDecoder & Codable models

Additional context

• wrote test cases for all File & Bucket Api Operations
• refactored StorageApis to use url instead of string when building endpoint urls
• added some documentation to Api methods

I made the initializer from StorageError public so it can be used from outside of the package. This allows developers to make wrappers over certain functions and they can return StorageError as result if needed.

For example, I've created this extension over StorageFileApi and I would like to return StorageError if I cannot convert UIImage to Data

What kind of change does this PR introduce?

Bug fix, feature, docs update, ...

What is the current behavior?

Please link any relevant issues here.

What is the new behavior?

Feel free to include screenshots if it includes visual changes.

Additional context

Add any other context or screenshots.

Add FoundationNetworking if available. This is allowing Linux platforms to compile the framework, since the migration of URL-related function to the FoundationNetworking framework.

What kind of change does this PR introduce?

• Bug fix

What is the current behavior?

• fetch return-type dependant on response
• data is then decoded with JSONSerialization and instances created manually

What is the new behavior?

• fetch returns response data directly, but will still attempt to decode and throw an error if the status code is not 2XX
• data is decoded using JSONDecoder & Codable models

Additional context

• also implemented updateBucket & updated createBucket, adding isPublic option
• wrote test cases for all File & Bucket Api Operations
• refactored StorageApis to use url instead of string when building endpoint urls
• added some documentation to Api methods

Bug report

I've noticed that JSON decoding has some issues (missing keys, optionals not handled) and that you're not using Codable to decode. Is there a particular reason for that?

As far as I'm aware, Codable is available on linux too according to this PR

The Bucket Model for example is almost entirely optional, which is not handled (maybe due to code generation from javascript?)

If there is no reason against implementation with Codable, I'd be up to doing that :)