stub_response does not accept the raw response from calling aws cli directly

[skippy]

if I call aws ec2 describe-instances and copy/paste that response into the ruby client stub_responses call, it doesn't work. If I run it through JSON.parse, it doesn't work.

it seems that stub_responses expects an internal representation of the raw aws response, including:

• running underscore on every key
• converting iso-8601 time representations to Time objects
• converting keys to symbols.

I really like the idea of saving expected respones and passing those in rather than constructing a ruby-specific construct.

does that make sense and does it seem reasonable? Here is the code I'm using to normalize an aws_response for the ruby sdk:

  def aws_normalize(json)
    json.keys.each do |k|
      value = json.delete(k)
      case value
      when Array
        value = value.map{|v| aws_normalize(v)}
      when Hash
        value = aws_normalize(value)
      when String
        # check to see if time
        time = Time.strptime(value, "%Y-%m-%dT%H:%M:%S.000Z") rescue nil
        value = time if time
      end
      new_key = k
      new_key = new_key.underscore if new_key.is_a?(String)
      json[new_key.to_sym] = value
    end
    json
  end

[trevorrowe]

The AWS SDK for Ruby accepts all input parameters as Ruby style hashes with snake_cased symbolized keys. This is the convention in Ruby. The AWS CLI uses JSON with non-inflected keys. That said, they are not the same as what goes over the wire. This is especially true for AWS Query and REST-XML based services. Similar to how the Ruby SDK standardizes the interface for Ruby, the CLI standardizes the input on JSON, regardless of the wire protocol.

Your method will work most of the time. It does however lack the context of what type of data you are translating. There are some context sensitive hashes that do not use symbolized snake_cased keys. These are hashes that represent user data. If you know the name of the operation, it would be possible to provide a context aware translation that does this correctly using the service API model.

[skippy]

hey @trevorrowe thank you for the prompt response!

comments:

• good point about the CLI and JSON. It is indeed nice to have standardized output.
• I understand your comment about ruby syntax, yet this is about stubbing a response, not calling a method on the aws sdk. You say:

If you know the name of the operation, it would be possible to provide a context aware translation that does this correctly using the service API model.

Is that documented anywhere? If not, lets definitely add it as it would be awesome to be able to take the JSON output of the aws CLI and pass that into a stubbed response.

thanks

[trevorrowe]

I did not mean to imply that the code exists, only that it would be possible to implement it correctly, but only if the operation is known.

It is not possible to stub the response correctly without knowing what response is being stubbed. The translation from the CLI requires knowledge about the shape of the data. Both tools share a definition of the API that could be used to guide the translation.

We can track this as a feature request and see what general interest there might be.

[skippy]

Yep, the operation is definitely known. I don't know if overloading :stub_respones , such as

      Aws.config[:sqs] = {
        stub_responses: {
          receive_message: File.read("sqs_receive_msg_response.json")
        }
      }

or via a different avenue is the right approach, but that is your call of course.

I would appreciate tracking this feature request. Do you do that via github or internally? Feel free to close this if you track it somewhere else.

[awood45]

I've added the feature request for this.

[mullermp]

Reopening - deprecating usage of Feature Requests backlog markdown file.