v2 API
Closed this issue · 5 comments
There doesn't appear to be any V2 sample code for any language here or from the website links (at least not that I can see - correct me if I'm wrong).
Closest thing I found was (which I'm working from):
https://github.com/paulirwin/harvest.net/tree/netcore-rewrite
I think the resources should at least be noted for which version they support.
But it's kind of confusing with the the site being like use v2, v1 is deprecated - and there appears to be no v2 samples to kick off from.
Hi @OpenSpacesAndPlaces! 👋
You are correct that we don't have any v2 API samples yet. I'm sorry about that! We are currently working on getting some added, though, and should have them added soon!
@OpenSpacesAndPlaces We're still working on adding more samples and polish but I wanted to go ahead and point you to what we have: https://github.com/harvesthq/harvest_api_samples/tree/v2/v2
Let me know if you run into any issues or if there's something else you'd like to see there!
Thanks @jasondew!
So far so good with respect to creating connections/querying data.
Things I've run into so far:
-
The documentation doesn't specify what fields are null-able - it's kind of a guess/check for the property types until it stops blowing up during de-serializing. The quick fix would have been to just mark all the fields in my code null-able, but my preference is to have accurate typing from a business logic/unit testing perspective.
-
The partial DTOs don't seem to be standardized across API requests (unless the intent is to expand them deferentially in the future.)
A quick example would be:
https://help.getharvest.com/api-v2/timesheets-api/timesheets/time-entries/ (client - id, name)
https://help.getharvest.com/api-v2/expenses-api/expenses/expenses/ (client - id, name, currency).
- It would helpful to have a way to enable larger paging sizes and/or skip paging in entirely - or possibly some kind of reporting/summary API (let me know if I missed anything).
At least one case where this would already be useful (already be used):
Dashboard of all clients -> all projects -> all billable time/expenses (not yet invoiced). Right now it means paging out all the requests (when I need all the data). To then sum just two fields
Thanks again!
That's wonderful feedback, thank you @OpenSpacesAndPlaces !
The documentation doesn't specify what fields are null-able - it's kind of a guess/check for the property types until it stops blowing up during de-serializing. The quick fix would have been to just mark all the fields in my code null-able, but my preference is to have accurate typing from a business logic/unit testing perspective.
I definitely agree that this would be a nice addition to the feedback and we'll look into it
The partial DTOs don't seem to be standardized across API requests (unless the intent is to expand them deferentially in the future.)
Standardization was a big goal for us with the v2 API so we'll get this fixed and review other nested objects to make sure that we're consistent.
It would helpful to have a way to enable larger paging sizes and/or skip paging in entirely - or possibly some kind of reporting/summary API (let me know if I missed anything).
Reporting APIs are on the roadmap, stay tuned!
No problem.
One minor thing that I thought I'd mention.
The API doesn't seem to give any info about bad url parameter values.
One quirk of C# is that boolean values convert to "True/False" vs "true/false" that is expected by the API.
I hadn't realized this initially - and I thought the API was correctly filtering data
I wrote a dumb little converter helper on my end to deal with that to make the problem go away.
Ideally the API would throw a 400 and/or give an indication it may not be doing what I think it is.