supporting Harvest API V2 about harvest.net HOT 11 OPEN

My initial prototype of this is here: https://github.com/paulirwin/harvest.net/tree/netcore-rewrite

This supports .NET Standard 2.0, GETs for the Clients and Companies Harvest v2 APIs so far, and uses Refit to remove the need for any implementation code for the APIs as that is all generated at runtime. Since Refit supports .NET Standard 1.4, we could support as far back as 1.4 with very little effort. Supporting .NET Standard means this library supports .NET Framework, .NET Core, UWP, Xamarin, and more. Since Refit is exclusively async, async support is the default and you can just call .Result/.Wait() to make them synchronous (in a context where that won't deadlock, of course). Also since Refit uses JSON.Net, we get easy serialization out of the box.

Example usage:

var harvest = new HarvestRestClient(myAccountId, myAccessToken);
var clients = await harvest.Clients.ListAllAsync();

Let me know your thoughts before I proceed further.

from harvest.net.

@paulirwin Looks pretty good. I'd be happy to use that as the jumping off point for 2.0 in this nuget.

from harvest.net.

It hasn't really come up yet. I'd welcome PRs.

from harvest.net.

I am looking into this and I think it's time for a radical rewrite of Harvest.Net to support API v2 and .NET Core (#63), due to RestSharp not supporting .NET Core. I have a prototype so far of what this could look like using Refit and I'm loving it. It is significantly less code (due to Refit creating the implementation for you) and will allow this project to move more nimbly.

Due to not using nearly any of the existing code, we can either create a new breaking-change version of Harvest.Net once this code is finished, or spin up a separate library (i.e. Harvest.NetCore) to avoid breaking any existing consumers of the library in either this or a separate repo. Thoughts?

from harvest.net.

I think a separate repo would be appropriate, especially if it's not gonna be backward compatible for the non-core users.

from harvest.net.

Alternatively, we could branch 1.0 into a permanent branch and continue maintenance and development there for existing users. This would maintain traction instead of fragmenting usage into multiple libs.

I'm not positive, but I think we could even use the same nuget.

from harvest.net.

@paulirwin Is it possible to show an implementation here? Just a simple console app that gets the token in the correct flow?

from harvest.net.

@kfrancis I don't have the OAuth-related bits hooked up yet but I will soon. However you can also use a Personal Access Token instead of an OAuth token in v2.

from harvest.net.

Props to @paulirwin.

There's no v2 API sample code (for any language I've seen) - it was a great starting point to get going from (we're just considering using Harvest for the first time, so using the deprecated v1 API made no sense).

Even better for our end, I was able to change the target framework to net45 and it just works. So far I have added Projects, ProjectTaskAssigment, Tasks, TimeEntries, and Users.

The weirdness though, is there API docs don't specify which fields are nullable. They also have strange/random partial dtos with different fields attached to other objects (e.g. TimeEntries has a bunch these). So there is an element of, fire it up, watch how it fails, tweak the settings.

Thanks again!

from harvest.net.

Any timeline on having this new version or branch or project released?

from harvest.net.

Just now finding this. Is this currently supporting V2?

from harvest.net.