Create issues for different API endpoints

[stephlocke]

We need issues filed that will help people start developing functions for the Hubspot API.

For each category e.g. deals, we need to identify any relevant get_ functions needed and any view functions over the top of the gets. So far for deals, companies, and pipelines I've done some work and used gets for each entity type. Some gets had very simple responses like deal properties so did not need further manipulation, but many need multiple functions for extracting different slices of data in a tabular way.

Each issue should provide instructions for:

• Where the docs are for the endpoint(s)
• What endpoints need covering (for now just data extraction)
• Recommendations for gets and tabular functions
• Suggested tests

[maelle]

I'm still reading the docs, I'm wondering whether endpoints functions could be created automatically from the specs.

[maelle]

:cry: https://community.hubspot.com/t5/APIs-Integrations/Are-hubspots-API-s-open-api-spec-or-actually-just-api-s-that-are/td-p/222418

[maelle]

This was a relevant convo https://github.com/rstudio/swagger/issues/1

[maelle]

As mentioned there, the other possibility is to have a minimal package à la gh.

Creating a minimal function à gh::gh() is in any case a good first step, to have it as a building block for all other functions and not repeat ourselves.

[maelle]

Not sure whether official https://app.swaggerhub.com/apis/myself899/testScribe/1.0.0

[maelle]

There must be some structured specs for the API somewhere, maybe not public, because the docs website is probably not manually updated (or is it?).

[maelle]

not sure it'd be best practice to web scrape the docs :smiling_imp:

[maelle]

https://community.hubspot.com/t5/APIs-Integrations/Public-Hubspot-API-specs-schema-Swagger-like/m-p/297729#M27966

[stephlocke]

I'd love for the functions to be at least scaffolded out automagically but the api is quirky so the deps definitely need thinking about manually. Esp as we probably need to rethink my naming convention 🙊

Happy for a one-off webscrape of the docs to identify the relevant list of endpoints and associated doc URL for the initial generation of the Issues.

[maelle]

Yep, I thought about that too, useful at least for issue opening.

[maelle]

Given the answer I got on the forum, I'll need to resort to "a one-off webscrape of the docs to identify the relevant list of endpoints and associated doc URL for the initial generation of the Issues.".

I've also just realized that once we have the issues, a place to advertise them to (first time) contributors would be that forum.

[maelle]

I am not in favour of opening one issue by endpoint right away because we'd be drowned in issues. Maybe one issue by entity is better, with a check list inside, one item being one endpoint. :thinking: The information collection is still under way, maybe seeing the final table will help us decide.

[maelle]

For each endpoint one needs to create the getter, and probably the getter test. Before calling for contributions #30 needs to be solved this way one could provide a skeleton. I think the authentication parts should also be solved.

[maelle]

To post issues https://emilyriederer.github.io/projmgr/reference/post_todo.html

If you're an #rstats developer still wanting to get some community support during @hacktoberfest , {projmgr} (now on CRAN) makes it easy to jot down those little issues in the back of your mind and push them up to your repo with the "hacktoberfest" label! pic.twitter.com/vdMl3iw3zX

— Emily Riederer (@EmilyRiederer) October 20, 2019

[maelle]

(I'm clearly not aiming for hacktoberfest at this point :slightly_smiling_face: )

[maelle]

Have script and test drafts inside a dev/ folder and link to that from the issues.

[maelle]

When all methods are supported, the dev folder will be empty.

[maelle]

Now issues have been opened for the endpoints to which @stephlocke had given the priority "2" (priority "1" were the endpoints that this package already supports).

Once they are tackled and feedback has been collected on how to make such issues more helpful, priority "3" endpoints should be taken care of with better issue templating.