API Days

 

July 16 - 17 2019

 

- Puru & Praneeta

Part I
MUST HAVE NOW

Highly recommend....

Things to consider when building an API

  • Start at db level
  • keep it to crud, nothing more complex
  • documentation is great!!  - open api is good to look into

 

testing using postman

  • Most of us already use postman to test internal and external apis
  • Most of us can write javascript
  • Needs no setup
  • We can use for free using a single shared account + gitlab
  • Newman (open source) can integrate with CI

  • {{Variable}} for environment and other variables

  • Can also setup using a postman call - eg call api to get jwt token, set it as env variable and then run all the tests

  • Monitor - runs at x interval, pings api and stores results to see later
    Postman Meetup on today for ci/cd

Example Created for Form builder Pricing (Setup time < 10 mins)

Part II

THE interesting BITS

Should consider these when building new things...

https://www.bearer.sh/

  • Easy integration with APIs
  • Main point ease of auth (supports all major ones)
  • Logs are parsed and displayed pretty well
  • Gives code to copy paste, supports Ruby, React. 
     

     

Bearer

.integration('github')

.auth('AUTH_ID') # OAuth user identity

.get('/orgs/bearer/repos', { query: { type: "public"}})

**Add comparison
NOTE: They have an integration with typeform, how do get people to integrate with POWr?

Mercure protocol

Mercure.rocks https://github.com/dunglas/mercure

  • For event driven api 
  • Seems like a good option to explore for us
  • Talked about Server Sent Events, Event source etc - real time updating of UI without polling
  • Compatible with most modern browsers and has polyfill for others.
  • Instead of server maintaining a persistent connection with client, the hub does so, ( Lambda functions  can maintain only few minutes) 

Security

Combination of topics by 2 speakers

  • Old forgotten apis, shadow apis - nobody really knows about these.You cannot secure what you are not aware of
  • Assume every call is an attack. Validate on client, front end controller, server side, API level
  • Set up decoy honey pots for hackers, an API which returns 200 but not used by anyone for real.
  • With ML can detect deviation from pattern of the API call, can be used to block 

  • No human expertise needed, catch missing rules, get added insights on api traffic

     

Security

Combination of topics by 2 speakers

  • Old forgotten apis, shadow apis - nobody really knows about these.You cannot secure what you are not aware of
  • Assume every call is an attack. Validate on client, front end controller, server side, API level
  • Set up decoy honey pots for hackers, an API which returns 200 but not used by anyone for real.
  • With ML can detect deviation from pattern of the API call, can be used to block 

  • No human expertise needed, catch missing rules, get added insights on api traffic

     

  • GraphiQL explorer by one graph
  • Exporter builds react code
  • Watch not save data that comes in to generate default values
  • Hasura - builds graphql from postgres
  • Kind of brilliant. Pretty seamless integration between local db and API data
  • Integrates with sheets (Excel)

 

OneGraph

Other links to look at

  • AsyncApi - Creating a standard like open api but for handling pub sub kind of apis - AsyncApi2.0 - capture event pub sub apis https://asyncapi.io/ RAML

  • https://a.ml/ - anything modeling languages AML, anything modeling framework - AMF

  • https://stoplight.io/ for complete API testing, documentation and schema design.

  • https://www.bearer.sh/ Zapier for developers, which looks like built in integration unlike zapier integration with minimal setup. Still on beta, but looks promising.

  • OpenAPI 3.0.0 (aka Swagger) when building API.
    https://swagger.io/

Made with Slides.com