Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send valid payloads to Readme API #29

Merged
merged 1 commit into from
Aug 12, 2020
Merged

Send valid payloads to Readme API #29

merged 1 commit into from
Aug 12, 2020

Conversation

JoelQ
Copy link
Contributor

@JoelQ JoelQ commented Aug 11, 2020

🧰 What's being changed?

This sends a valid hardcoded payload (in the form of the data.json file)
to the Readme API with all the proper headers and authentication.

The middleware now takes an API key during initialization and no longer
needs an endpoint which has become a constant.

The hard-coded data we wrote is valid according to HAR
1.2
. We noticed that
there are some required fields from the spec that are neither mentioned
by the API nor used in the nodejs implementation. We decided to include
them for validity sake and at some point the backend might want to fully
support the HAR 1.2 spec.

The added fields are:

  • entries.cache
  • entries.timing
  • entries[].request.cookies
  • entries[].request.headerSize
  • entries[].request.bodySize
  • entries[].response.cookies
  • entries[].response.headerSize
  • entries[].response.bodySize
  • entries[].response.redirectURL
  • entries[].response.httpVersion

Some of these are empty arrays or objects but the keys are required to
be present.

As part of our development process, we introduced json-schema to check
the generated JSON we use (for now the static JSON file). We wrote a
schema file for the Readme.io-specific structure but were able to re-use
an existing implementation for the HAR
format
.

🧪 Testing

There is an automated test the uses json-schema to guarantee the JSON is in the right format. We also manually tested this with the following Rack app:

$LOAD_PATH << File.expand_path("../path/to/metrics-sdks/packages/ruby/lib", __FILE__)
require "readme/metrics"

class ApiApp
  def call(env)
    puts "=== API ==="
    [200, {}, ["Ok"]]
  end
end

map "/api" do
  use Readme::Metrics, "YOUR_API_KEY_HERE"
  run ApiApp.new
end

run it on the command-line with:

$ rackup

Make a request:

$ curl http://localhost:9292/api/foo

then log into Readme.io dashboard and expect to see your request(s) there. Note that all the data will be from the hard-coded JSON file rather than actual data from the request.

ReadMe 2020-08-11 16-57-11

@JoelQ
Copy link
Contributor Author

JoelQ commented Aug 12, 2020

Discussed IRL with @joshuaclayton, everything is good to go 👍

This sends a valid hardcoded payload (in the form of the `data.json` file)
to the Readme API with all the proper headers and authentication.

The middleware now takes an API key during initialization and no longer
needs an endpoint which has become a constant.

The hard-coded data we wrote is valid according to [HAR
1.2](http://www.softwareishard.com/blog/har-12-spec). We noticed that
there are some required fields from the spec that are neither mentioned
by the API nor used in the nodejs implementation. We decided to include
them for validity sake and at some point the backend might want to fully
support the HAR 1.2 spec.

The added fields are:

* `entries.cache`
* `entries.timing`
* `entries[].request.cookies`
* `entries[].request.headerSize`
* `entries[].request.bodySize`
* `entries[].response.cookies`
* `entries[].response.headerSize`
* `entries[].response.bodySize`
* `entries[].response.redirectURL`
* `entries[].response.httpVersion`

Some of these are empty arrays or objects but the keys are required to
be present.

As part of our development process, we introduced json-schema to check
the generated JSON we use (for now the static JSON file). We wrote a
schema file for the Readme.io-specific structure but were able to re-use
an [existing implementation for the HAR
format](https://github.com/ahmadnassri/node-har-schema).
@JoelQ JoelQ merged commit cc0199f into master Aug 12, 2020
@JoelQ JoelQ deleted the hardcoded branch August 12, 2020 14:25
@erunion erunion added ruby Issues related to our Ruby SDK and removed area:ruby labels Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ruby Issues related to our Ruby SDK
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants