Investigate usage of Postman's Newman command line for API requests

[chazgorman]

Postman (https://www.getpostman.com/) has a nodejs command line runner named Newman.

It may prove useful as a guide when designing koop, or perhaps it could be integrated in some ways. Postman's story is more based around API testing, but API requests are API requests whatever the user's goal is.

https://www.getpostman.com/docs/newman_intro https://github.com/postmanlabs/newman

A lot of Postman/Newman's power comes from it's ability to chain requests, feeding the results of one request into another request's variables (ie. fetch the ID's of the top-5 most active user's tweeting on a hashtag, and then request the 5 latest tweets for each of those users).

Leveraging Newman as part of this project may make fetching data from API's easier, leaving this project to focus into converting the results to geo-based data.

Thanks for reading.

[dmfenton]

Hi thanks for sharing this! While Newman is interesting, I don't think its a good fit for this project. I'd love to hear how you're using Koop now if you are willing to share.

[chazgorman]

Thanks for the reply. I'm not actually a user of koop, but I do like the goals. I am a developer in the Esri Canada Ottawa office. Prior to that I worked on the data-connector team at Klipfolio (www.klipfolio.com), which had a similar goal to koop (connecting to a variety of data sources whether they be REST/DB, etc.). But those data sources were fed into a business dashboard with more typical widgets, so there wasn't a need to translate them (ie. to spatial data set).

I see the value-add of koop being the translation of data returned from APIs into a spatial data set to be consumed by GIS. The first step of the process, getting the data from an API is solved (Newman), whether you leverage the design or the code, which I thought would leave koop to focus on the translation part. The Postman ecosystem provides a number of concepts that are very useful when a user's data requirements become more complicated:

-Looping requests (for paging APIs) -Variables (parameter-ized requests) -Requests as configuration (for sharing, building requests through a UI) -Environments (suite of variables in which to run requests)

At Klipfolio we had our own connector system written Java, but it would've done well to leverage this ecosystem to avoid reinventing the wheel.

On Thu, Apr 13, 2017 at 12:37 PM, Daniel Fenton notifications@github.com wrote:

Hi thanks for sharing this! While Newman is interesting, I don't think its a good fit for this project. I'd love to hear how you're using Koop now if you are willing to share.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/koopjs/koop/issues/297#issuecomment-293954018, or mute the thread https://github.com/notifications/unsubscribe-auth/AIBTqa7Hx04Rd30apvWjKXUeHoY_RQaqks5rvk87gaJpZM4MzH2Q .

[dmfenton]

I think Newman could be used for writing providers https://koopjs.github.io/docs/specs/provider/ but I don't think it makes sense to bring it into the core, since the core's job is not to handle translation from 3rd party APIs.