amadeus4dev-examples / amadeus-ruby Goto Github PK

Description

Update the ruby SDK to support the new APIs

Maintenance Requirements

1. Source Control

• 1.1 The source code for the SDK must be maintained within Git version control
• 1.2 Development of new features should happen on feature branches
• 1.3 Feature branches should pass all tests and linting before they can be merged into the master branch
• 1.4 Source control should contain tags for each release of the SDK
• 1.5 The master branch should be kept in a condition that allows for direct use through checkout
• 1.6 The source code must be hosted publicly
• 1.7 The source code should use GitHub for public hosting
• 1.8 The source code should not include build packages, compiled assets, or any other intermediary files used to package the source code into a release

2. Releases & Versioning

• 2.1 The SDK must use Semantic Versioning to increment the version number as changes are made
• 2.2 The version number of the SDK could be incremented when the SDK has gathered enough changes to warrant a new release
• 2.3 For every release a tag must created within Git
• 2.4 New releases should be deployed automatically to the package manager using the CI server
• 2.5 For every new release the CHANGELOG file must to be updated with the Major, Minor and Patch changes
• 2.6 Releases must be pushed to package managers as an Amadeus user not exclusively under any personal accounts
• 2.7 The version number of the SDK should be independent of the API version
• 2.8 A release package should not include unnecessary source code files or intermediarry files for the SDK.
• 2.9 A release package must include the documentation README file
• 2.10 A release package must include the LICENSE file
• 2.11 A release package should include the CHANGELOG file
• 2.12 The name of the SDK should follow language best practices, and be one of amadeus, Amadeus, or amadeus/amadeus.
• 2.13 If the preferred name of the SDK is not available, it could be one of amadeus-sdk, AmadeusSDK, or amadeusdev/amadeus.
• 2.14 The name of the SDK must exclude the programming language (e.g. not amadeus-php) or a reference to this being an SDK client library (e.g. not amadeus-sdk)
  practices, and be one of amadeus, Amadeus, or amadeus/amadeus.
• 2.15 As soon as the first public version of the library has been signed off, the version should be bumped to 1.0.0

3. CI Server

• 3.1 A Continuous Integration (CI) server must be used to automatically test any branch of the Git repository
• 3.2 The CI server should be Travis CI.
• 3.3 The CI server must test against all current LTS language versions
• 3.4 The CI server could test against popular non-LTS versions
• 3.5 The CI server could test on different platforms, including Windows, Linux, and macOS.
• 3.6 The CI server should test new Git tags, and build and push the package to the package manager

Additional Content Requirements

4. Documentation

• 4.1 The SDKs must include a README file
  • 4.1.1 The README file should include a version badge
  • 4.1.2 The README file should include a test status badge
  • 4.1.3 The README file must link to the LICENSE file
  • 4.1.4 The README file should be written in Markdown
  • 4.1.5 The README file must have instructions on how to install the SDK using a package manager
  • 4.1.6 The README file could have instructions on how to install the SDK from version control
  • 4.1.7 The README file must have instructions on how to initialise the SDK with the API credentials
    • 4.1.7.1 Where possible, the initialised client variable should be named amadeus. For example, amadeus = new Amadeus::Client()
  • 4.1.8 The README file should document all the different ways the SDK can be initialized
  • 4.1.9 The README file must include a basic sample on how to make a first API call
  • 4.1.10 The README file must link to the developer portal
  • 4.1.11 The README file should link to documentation on the developer portal
  • 4.1.12 The README file must document any installation requirements and prerequisites
  • 4.1.13 The README file should to official support channels
  • 4.1.14 The README file must document where a developer can find their API credentials
• 4.2 The SDKs should have its public methods documented in a way that allows for autogenerated method documentation. For example, for Ruby this would be yard and for Java this would be using Javadoc.
• 4.3 The SDKs could use the CI server or any other build tool to autogenerate the method documentation on deploy
• 4.4 The GitHub repository should have a title in the format "Ruby library for the Amadeus travel APIs"
• 4.5 The GitHub repository should have the following tags: amadeus, travel, flights, hotels, sdk, library
• 4.6 The SDKs must include a CHANGELOG file
• 4.7 The SDKs must include a CODE_OF_CONDUCT file
• 4.8 The SDKs must include a CONTRIBUTING file
  • 4.8.1 The Contribution Guidelines should include instructions on how to run the SDK in development/testing mode.
• 4.9 The SDKs must include a ISSUE_TEMPLATE file
• 4.10 The SDKs must include a PULL_REQUEST_TEMPLATE file
• 4.11 The SDKs must include a SUPPORT file

Templates for a lot of these files have been provided in the templates folder

5. Testing

• 5.1 The SDKs must be thoroughly tested
• 5.2 The tests should have integration tests to make the API calls
• 5.3 The tests should test response objects
• 5.4 The tests must not actually make any HTTP calls to the API in testing and instead use some kind of VCR method
• 5.5 The tests must not include actual API credentials

6. Linting

• 6.1 The SDKs must have their files linted
• 6.2 The linting must ensure that tabs/spaces are consistently used
• 6.3 The linting should ensure no trailing whitespace is left in the code
• 6.4 The linting should ensure quotes and brackets are consistently applied
• 6.5 The linting could ensure semicolons are present when needed
• 6.6 The linting could ensure comments are present on public methods

Dependencies & Infrastructure Requirements

7. Dependencies

• 7.1 The SDK must limit its runtime dependencies
• 7.2 The SDK should have no runtime dependencies
• 7.3 The SDK could use any amount of development and test dependencies

8. HTTP Client

• 8.1 The SDK must use a well supported HTTP client
• 8.2 A HTTP client from the standard libraries should be used
• 8.3 The HTTP should support proxies
• 8.4 The SDK could allow a developer to provide an alternative HTTP client

9. Logging

• 9.1 The SDK must be able to log activities to a logger
• 9.2 The logger should use the default runtime log
• 9.3 The logger must allow enabling/disabling of debug mode per instance
• 9.4 The logger should allow a developer to provide an alternative logger

10. Reporting

• 10.1 The SDK must identify requests to the API as originating from the SDK
• 10.2 The SDK must report the SDK version number to the API
• 10.3 The SDK should report the language version number to the API
• 10.4 The HTTP client should use the following format user agent to identify the library:
  • Specification: library_name/library_version language_name/language_version
  • Example with known language version: amadeus-ruby/1.0.0 ruby/2.4.2
  • Example with unknwon language version: amadeus-ruby/1.0.0 -
• 10.5 The SDK should allow a developer to provide an additional custom app id and custom app version to be passed along in the user agent.
  • Specification: library_name/library_version language_name/language_version app_name/app_version
  • Example: amadeus-ruby/1.0.0 ruby/2.4.2 test_ios_app/1.0.0

Initialization & Interaction Requirements

11. Initialization

• 11.1 The SDK could be included or imported when needed, and where applicable must use the amadeus, com.amadeus.developer, or Amadeus package name
• 11.2 The SDK should reside in its own namespace and avoid polluting the global namespace
• 11.3 The actual client object for the SDK should exist as a subclass within the Amadeus namespace where the language allows. For for example Amadeus::Client in Ruby, or Amadeus\Client in PHP
• 11.4 The SDK client must allow for the creation of multiple clients per runtime environment, allowing the creation of multiple clients with different credentials
• 11.5 The SDK client must be able to accept SDK credentials as method parameters
• 11.6 The SDK client should accept the SDK credentials implicitly as environment variables AMADEUS_CLIENT_ID and AMADEUS_CLIENT_SECRET
• 11.7 The SDK client must accept a parameter to turn set the logger level
• 11.8 The SDK client should be able to implicitly accept the debug level as environment variable AMADEUS_DEBUG
• 11.9 The SDK client should be able to accept an alternative logger object
• 11.10 The SDK client could accept an alternative HTTP client
• 11.11 The SDK client must allow selection of the base URL by name (test and production)
• 11.12 The SDK client must allow for setting a custom base URL directly

12. Namespacing

• 12.1 The SDK should use namespaced methods to create a match between the API and the SDK
  • GET /v1/flights : amadeus.flights.get
  • GET /v2/hotels/offers: amadeus.hotels.offers.get
• 12.2 The SDK could use resource IDs as parameters to the namespace, or as a name or unnamed parameter to the call used to execute the API call
  • GET /v1/hotels/123 : amadeus.hotels(123)
  • GET /v1/hotels/123 : amadeus.hotels.get(123)
  • GET /v1/hotels/123 : amadeus.hotels.get(id: 123)
• 12.3 The SDK should limit API calls when selecting sub resources. All of these should make 1 API call only
  • GET /v1/hotels/123/hotel-offers : amadeus.hotels(123).offers
  • GET /v1/hotels/123/hotel-offers : amadeus.hotels.get(123).offers
  • GET /v1/hotels/123/hotel-offers : amadeus.hotels.get(id: 123).offers
• 12.4 The SDK could drop the HTTP verb methods where lazy loading is possible
  • GET /v1/flights/123/legs : amadeus.flights(123).legs() (should make 1 API call only)
  • GET /v1/flights/123/legs/345 : amadeus.flights(123).legs(345) (should make 1 API call only)
• 12.5- The SDK could convert the API namespace (e.g. reference-data) to a more idiomatic format (e.g. reference_data or ReferenceData)

13. Method Syntax

• 13.1 The SDK API calls should allow for a method to fetch all records for a resource with or without any parameters
  • Example: amadeus.flights().get() : GET /v1/flights
  • Example: amadeus.flights().get({ foo: 123 } : GET /v1/flights?foo=123
• 13.2 The SDK API calls should allow for a method to take a record ID to fetch a specific resource
  • Example: amadeus.flights(123).get() : GET /v1/flights/123
• 13.3 When making a POST or PUT request, the SDK API calls should accept a key/value data structure for the data to be submitted
  • Example: amadeus.flights().post({ from: "LHR", to: "LAX" })
• 13.4 In asynchronous programming languages, the SDK API calls should allow for a callback method to be provided, or a promise to be returned
  • Example with callback amadeus.flights().get(params, callback_function)
  • Example with promise amadeus.flights().get(params).then(...).catch(...)
• 13.5 The SDK API calls should return objects or other structured data
  • 13.5.1 The SDK must parse the JSON returned from the API
  • 13.5.2 The SDK should raise an exception if the JSON could not be parsed
  • 13.5.3 The SDK should raise an exception if the parsed object is an error object

14. Error Handling

• 14.1 The SDK should raise an exception for any request that did not result a HTTP 200 or 201 response code
• 14.2 The SDK should differentiate between different errors
  • 14.2.1 The SDK should raise a specific exception when a transport error occurs (e.g. if the API could not be reached, or unexpected data was returned from the API)
  • 14.2.2 The SDK should raise a specific exception when a client error occurs (e.g. bad credentials were used, or incorrect data was sent to the API, basically any 400 error)
  • 14.2.3 The SDK should raise a specific exception if a server error occurred
• 14.3 The SDK should prefer using native exceptions and errors over returning error objects
• 14.4 The SDK should not validate submitted data within the SDK, instead leaving this task to the API and raising exceptions on receiving an error response from the API
• 14.5 The SDK should allow the inspection of request and response objects on exception

API Mapping Requirements

15. API Calls

• 15.1 The SDK should define the reference-data namespace
  • 15.1.1 The SDK must implement the GET /v2/reference_data/urls/checkin-links endpoint
    • Example: amadeus.reference_data.urls.checkin_links.get({ airline: 'BA' })
  • 15.1.2 The SDK must implement the GET /v2/reference_data/locations endpoint
    • Example: amadeus.reference_data.locations.get({ keyword: 'LON' })
  • 15.1.3 The SDK must implement the GET /v2/reference_data/locations/airports endpoint
    • Example: amadeus.reference_data.locations.airports.get({ latitude: '0.0', longitude: '0.0' })
• 15.2 The SDK should define the shopping namespace
  • 15.2.1 The SDK must implement the GET /v1/shopping/flight-destinations endpoint
    • Example: amadeus.shopping.flight_destinations.get({ origin: 'LAX' })
  • 15.2.2 The SDK must implement the GET /v1/shopping/flight-offers endpoint
    • Example: amadeus.shopping.flight_offers.get({ origin: 'LAX', destination: 'LHR', departureDate: '2020-12-01' })
  • 15.2.3 The SDK must implement the GET /v1/shopping/flight-dates endpoint
    • Example: amadeus.shopping.flight_dates.get({ origin: 'LAX', destination: 'LHR' })
• 15.3 The SDK should define the travel/analytics namespace
  • 15.3.1 The SDK must implement the GET /v1/travel/analytics/fare-searches endpoint
    • Example: amadeus.travel.analytics.fare_searches.get({ origin: 'LAX', sourceCountry: 'US', period: 2015 })
  • 15.3.2 The SDK must implement the GET /v1/travel/analytics/air-traffics endpoint
    • Example: amadeus.travel.analytics.air_traffics.get({ origin: 'LAX', period: '2015-07' })
• 15.4 The SDK should define the shopping/hotels namespace
  • 15.4.1 The SDK must implement the GET /v1/shopping/hotel-offers endpoint
    • Example: amadeus.shopping.hotel_offers.get({ cityCode: 'LAX' }
  • 15.4.2 The SDK must implement the GET /v1/shopping/hotels/:hotel_id/hotel-offers endpoint
    • Example: amadeus.shopping.hotels.get(123).hotel_offers.get({ checkInDate: '2018-12-01', checkOutDate: '2018-12-03' })
  • 15.4.3 The SDK must implement the GET /v1/shopping/hotels/:hotel_id/offers/:offer_id endpoint
    • Example: amadeus.shopping.hotels.get(123).hotel_offers.get(345)

16. Responses

• 16.1 The SDK should return a response object where possible, instead of the JSON data directly
• 16.2 The SDK should include a method to access the raw JSON data
  • Example: amadeus.reference_data.urls.checkin_links.get({ airline: '1X' }).json returns { meta: ..., data: [...] }
• 16.3 The SDK could include a method to access the data attribute from the returned JSON, if there is any
  • Example: amadeus.reference_data.urls.checkin_links.get({ airline: '1X' }).data returns [...]
• 16.3 The response objects should allow for easy pagination where needed
  • Example: response = amadeus.foo.bar(); next_response = result.next();
• 16.4 The response object could allow for access of the returned data as methods on the object
  • Example: flight_offer = amadeus.get_flight_offers(); first_leg = flight_offer.flight.airline.name;
• 16.6 The response object should be able to deal with any new parameters returned from the API without needing an SDK update. In other words, the class definition of response objects should not define the attributes of the object statically

Specific Language Requirements

17. Ruby

• 17.1 The SDK must support Ruby 2.2+
• 17.2 The SDK should support JRuby

The documentation says the opposite https://amadeus4dev.github.io/amadeus-ruby/Amadeus/Namespaces/Shopping/FlightOffersSearch.html#post-instance_method

I have a question about the maxFlightTime?

I asked it on Stack Overflow here:
https://stackoverflow.com/questions/66391335/how-to-set-the-maxflighttime-in-a-flight-offers-search-with-the-amadeus-api

Here is the question:
I am making a POST to the Amadeus API for flight offers.

I am trying to set the maxFlightTime parameter.

The API documentation says:

maxFlightTime number example: 200 This option allows to modify the value for the Elapsed Flying Time (EFT) masterPricer option
https://developers.amadeus.com/self-service/category/air/api-doc/flight-offers-search/api-reference
My question is: What does this parameter expect? The documentation says a number and provides 200 as an example.

What does the number represent? Is it minutes, hours, or something different?

• Enable travis
• Make the project public
• Remove docs from repo
• Bump version to 1.0.0
• Update changelog
• Release 1.0.0
• Remove checklist issue and this issue
• Fix code sample to use backticks in README
• Update README to use rubygems rather than gemfury
• Cancel gemfury account
• Check and fix all links in README
• Decouple from cbetta github account by setting up an amadeus*** github account
  • Decouple travis from this GH account
  • Decouple codeclimate from this GH account

Description

I am trying to use amadeus.shopping.hotel_offers_by_hotel.get(hotelId: "RWPARRCR")
The response is positive the the result is always empty.
I tried with different hotel ID maybe I am missing something out there...

Steps to Reproduce

1. amadeus.shopping.hotel_offers_by_hotel.get(hotelId: "RWPARRCR")
2. => #<Amadeus::Response:0x00005602d532ae78 @http_response=#<Net::HTTPOK 200 OK readbody=true>, @request=#<Amadeus::Request:0x00005602d534b600 @host="api.amadeus.com", @port=443, @ssl=true, @scheme="https", @verb=:GET, @path="/v2/shopping/hotel-offers/by-hotel", @params={:hotelId=>"RWPARRCR"}, @bearer_token="Bearer i0q0KquqTF5EYsauqdIhQ6rqXRo8", @client_version="3.3.0", @language_version="2.5.1", @app_id=nil, @app_version=nil, @headers={"User-Agent"=>"amadeus-ruby/3.3.0 ruby/2.5.1", "Accept"=>"application/json, application/vnd.amadeus+json", "Authorization"=>"Bearer i0q0KquqTF5EYsauqdIhQ6rqXRo8"}, @http_request=#<Net::HTTP::Get GET>>, @status_code=200, @parsed=true, @body="{}", @result={}, @data=nil>

__Expected Behavior: I should get the list of the rooms that are available

__Actual Behavior: I get an empty answer

__Stable Behavior? 100%

Versions

[What version of Ruby/Rubygems are you running? What Operating System are you on?]
2.5.1

Checklist

Please make sure you checked the following:

• Are you running Ruby 2.2+? Yes
• Did you download the latest version of this gem? 3.3.0

Description

A new endpoint has to be supported for Airport & City Search

/v1/reference-data/locations/{locationId}

Checklist

• Update the Ruby SDK to support the new endpoint

Description

I've been trying to use e_reputation but it's not working

Steps to Reproduce

1. amadeus.e_reputation.hotel_sentiments.get(hotelIds: 'SJNYCAJA,TELONMFS')
2. Result -> NoMethodError (undefined method `e_reputation' for #Amadeus::Client:0x000055adba09e850)

__Expected Behavior: e_reputation is a method

Actual Behavior: e_reputation not a method

Stable Behavior? 100%

Versions

[What version of Ruby/Rubygems are you running? What Operating System are you on?]
Ruby 5.2

Checklist

Please make sure you checked the following:

• Are you running Ruby 2.2+? Yes
• Did you download the latest version of this gem? Yes

https://developers.amadeus.com/self-service/category/air/api-doc/flight-availabilities-search/api-reference

https://developers.amadeus.com/self-service/category/air/api-doc/branded-fares-upsell/api-reference

Description

Update the contributors guide to add that all files need to be added to the git repo to be used in the library.

I am having a lot of difficulty using pagination, and the documentation on pagination in this repo and the API documentation in Amadeus's site is not clear on usage.