Good question. Have you noticed the 5 protocol types given in the “metadata” of each api? They are json, rest-json, rest-xml, query, and ec2. Almost all new services are being released using the “json” protocol. Most of the older APIS, making up the majority of services use query.
Query is a RPC style protocol, where requests are sent via POST where the body of the request are url encoded querystrings. The response body is returned as XML.
The ec2 protocol is very close to the query protocol, but not quite. It diverges in a few ways. Primarily in how the input is serialized, but also slightly on output. It does not contain that extra wrapping element that standard query services use. In the Ruby SDK i have a different response handler that extends the query handler, but does not apply a wrapping element for parsing.
The waiters are defined as JSON documents. For example, here are the watiers for Glacier: https://github.com/aws/aws-sdk-ruby/blob/master/aws-sdk-core/apis/Glacier.waiters.json
Basically a waiter has a name, default delay and max attempts, and then a list of acceptors that can fail or succeede the watier. There are a few matcher types, you can look at the other waiters in the same folder for more examples. If you put something together that you are happy with, please feel free to submit a pull-request and I’ll review it.
Aws::EC2::Vpc#create_tagsright after creating the VPC, though, I got an
Aws::EC2::Errors::InvalidVpcIDNotFounderror, I assume because it hadn't propagated across aws. Is this what I'd want a
client = Aws::S3::Client.new(
resp = client.list_objects( bucket: 'my-backup')
client = Aws::S3::Client.new( access_key_id: ENV['AWS_ACCESS_KEY_ID'], secret_access_key: ENV['SECRET_ACCESS_KEY'], region: 'us-west-2' ) resp = client.list_objects( bucket: 'my-backup')
Aws::S3::Errors::PermanentRedirect: The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint. /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/seahorse/client/plugins/raise_response_errors.rb:15:in call' /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/aws-sdk-core/plugins/s3_sse_cpk.rb:18:incall' /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/seahorse/client/plugins/param_conversion.rb:22:in call' /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/aws-sdk-core/plugins/response_paging.rb:10:incall' /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/seahorse/client/plugins/response_target.rb:18:in call' /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/seahorse/client/request.rb:70:insend_request' /Users/tischler/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/aws-sdk-core-2.0.26/lib/seahorse/client/base.rb:216:in `block (2 levels) in define_operation_methods'
If you rescue that error, you can inspect the HTTP response body:
begin resp = client.list_objects( bucket: 'my-backup’) rescue Aws::S3::Errors:: PermanentRedirect => error puts error.context.http_response.body.read end
My guess is the bucket you are addressing is not in the ‘us-west-2’ region. You can call
#get_bucket_location to determine the actual region.
I've considered guessing, but this proved problematic, as it is not possible to know if the 404 is a result of a no such bucket or no such key.
We need to change this in the docs to reflect the SDK will raise a NotFound.
@sirmxanot In the “Parameters” section of the
#wait_until method you linked documentaiton for, it indicates that the accepted waiter names and the operations they call are specified in the
#waiter_names method. It is linked from there. In the
#waiter_names method, it shows the API call being pulled and links to that: