Description

As we sometimes need to download files the framework should provide the possibility to do so.

Description

It shall be possible to cancel a request.

Why are handlers not anonymous lambda implementation like DownloadHandler, DownloadExecutor, DownloadExecutorDelegate... ?

The API is clean but complicated is it possible to reduce the API requirements and complexity of executor stuff?

Data received or provided to an endpoint is currently decoded/encoded via the decoder property (encoder respectively). These properties are of type JSONDecoder/JSONEncoder. We should introduce protocols which abstract the decode / encode function that are used in the Client class. This what we would be more flexible what kind of object we want to decode/encode. This way it would be possible to work with objects other then JSON (e.g. XML)

If a download via the download method in Client succeeds the completion handler is called twice:

The first call is triggered by downloadExecutor(_ downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL). The second by downloadExecutor(_ downloadTask: URLSessionDownloadTask, didCompleteWithError error: Error?) with error = nil.

Since download(url: URL, progressHandler: DownloadHandler.ProgressHandler, _ completion: @escaping DownloadHandler.CompletionHandler) offers a completion handler (and not some delegation), completion should only called once after the internal downloadTask has finished.

Description

As in some apps we need to have a no internet connection handling we should also embed this functionality into the framework. Idea would be to have a response interceptor which checks for the response error like (error as? URLError)?.code == URLError.Code.notConnectedToInternet and provide an error to the callee.

Also check out the NetworkReachabilityManager included in Alamofire for reference.

Some classes and protocols are named Executer and some are named Executor we should define a single description and stick to it for API consistency

The URLFactory is a class overhead because it does only provide a single make method. Instead of defining that class it would make more sense to add a private extension to the Client.

We should not separate interceptors in our client initialization, sometimes it is very useful to let implement ResponseInterceptor and RequestInterceptor together in a single class.

Both words are used in the current version. No one of them is wrong but this could make us be confused during implementation or debugging. I'd suggest to keep just one of them, not both.

The default implementation of the Logging interface should be moved to an optin micro framework and be removed from the main project because it is not part of networking at all.

Description

When requesting an endpoint which delivers a lot of data it might be paginated so we shall also include a handling for it within the framework.

Description

When downloading files we shall add a caching mechanism so large files do not have to be requested multiple times.

Description

We need to add a simple way to send multipart requests.

Description

Provide the possibility to set the timeout values from outside of the framework.

The public interface of the CancellableRequest only includes a cancel method and an identifier. It doesn't contain any informations about a request and is also only intended to be used for a request cancellation.

My suggestion is to rename the CancellableRequest into CancellationToken, RequestToken or define a proper interface to represent a non opaque request.

Description

Make the request caching policy configurable.

What is the exact purpose of an Executor and which other term could be used to make it more descriptive for users?

Description

In some cases we need to send multiple requests at the same time and only want to react when every response was successfully received and not have to check manually if all responses have been received and then react on it.

The idea behind this mechanism is to have a single function where to give multiple request having one callback where the result of all requests come at once.

Description

To be able to be highly flexible we shall add a mechanism where we provide such functionality like logging or setting headers by having a middleware component which has a process function which takes the request, manipulates it and finally returns it so other middleware components can process it further.

So for example when having a log middleware it will just log the request and return it.

These middleware components shall be exchangeable and extendable so when having the need to add a special handling one implements a middleware component conforming to the existing components and add it to the middleware stack.

Description

If iOS 13 is available the combine syntax shall be useable.

Description

The background download functionality has to be improved as well as documented so the programmer knows what to enable in the app to be able to do background downloads.

Furthermore it may be tested on other scenarios rather than just downloading a test file from a public server.

Description

The current file structure within the project should be taken into consideration.

To make sure that our framework is buildable at anytime we should integrate it into our CI.

Description

The current error handling must be improved. The defined APIError enum has to be taken into consideration and may be removed and improved by a better way of handling possible errors.

Description

The framework should provide a possibility to upload files.

Note

Only upload tasks from a file are supported. This basically means that you’ll have to upload from a file. Save the file locally first and start uploading from that file location. Uploads from data instances or a stream fail directly after the app exits.

What to do

• API definition
• Client initialisation
  • Base URL

Description

As sometimes one needs to send a request which differs from the ones normally send using the framework, we should also provide the possibility to send a request which is created outside of the framework.

Description

As logging is a vital part of the framework we need to provide a default logging middleware component which can be added to the middleware stack or may be added by default if the app is run in DEBUG mode or make it configurable if the middleware component is added or not.

Consider adding multiple log levels.

The MultipartType and MultipartContentType enums seam to be incomplete and also is not extensible.

Instead of using an enum you could use a struct wrapper type with a String as raw value and provide named cases as static members in extensions. In this case a user would be able to define custom types.

Description

As some requests may use query parameters we should also embed an easy way to add those. Also keep in mind that the URL encoding is taken into consideration.

Description

While testing the framework within an app we noticed that the completion handler is called on a background thread which causes the an app crash. To prevent this we should move the completion handler calling to the main thread.

Description

There are several hard coded strings within the framework which might be extracted into a constants component. Maybe taking also MultipartContentType and MultipartType into consideration.

All interceptors which are currently implemented shouldn't be part of the networking framwork and moved to domain specific micro framworks.

Description

As in some cases we only need to add a path component like an id or similar to the endpoint URL and not send any data with the request we must provide this functionality.

The HTTPStatusCodeType should not contain type as postfix because it is clear that it is a type, also it seams that it is incomplete yet please provide all possible status codes or just replace the type with an Int.

Description

To be able to differentiate between a 200 OK and a 200 Created we need to extend the HTTPStatusCodeType.

Please provide a minimum README even if the project does not contain a release version yet.

Description

As sometimes files may be large and thus downloading them takes time we shall provide a progress to be able to display it to the user so he or she is aware of the long running task.

By implementing a mock request interceptor we are able to return responses according to a specific URL so we can remove the dependency to the Postman environment.

The Client is leaking its private URLSession out in the initializer public init(configuration: Configuration, sessionConfiguration: ((inout URLSession) -> Void)? = nil) but stores it as a private member. Consider making the session public or remove the configurability from the initializer.

Description

In rare cases we need to send multiple requests but they need to be executed in a synchronous way so we need to provide an easy way to do it.

Maybe this can be done by using a queuing mechanism but we need to discuss this in more detail as soon as this ticket will be tackled.

Add Obj-C support to help migrate legacy projects into modern APIs. It would be beneficial to support Obj-C so we would be able to migrate Obj-C based projects first into Obj-C with Jetworking and then from Obj-C Jetworking into Swift.

Description

The framework should have a default set of header fields which can extended by custom header fields as some of the APIs require the app to have them set.

Description

As not all requests require a response type, for example deleting an item, the framework should provide a possibility to send fire and forget calls.

Currently in the tests we use a VoidResponse being a Codable which in our opinion is not the best way of handling such case.

The postman response can be used to validate if the the mock body of the post, put and patch request were sent correctly. Also the arguments of a get request can be validated this way.

The Interceptor protocol is empty and is split into RequestInterceptor and ResponseInterceptor. My suggestion is to combine both API requirements into the Interceptor protocol and remove the other two protocols. An interceptor should be able to manage and manipulate the entire request response sequence. To avoid boilerplate code in user based application we could provide a default implementation or make the implementation of the methods optional.

It is also possible to use anonymous lambdas in Swift also with Obj-C support, why do we prefer to use delegates in a pure Swift Framework which doesn't depend on Apple Framework interfaces?

Description

As currently background upload functionality is not working when switching within the tests to background execution we should tackle this as soon as possible.

Furthermore the multipart upload functionality should be tested more. The server I tested with was not sending any errors when having wrong multipart type or multipart content type.