Open DerMika opened 8 years ago
Slighly unrelated;
Even more ideal would be to straight off emulate Amadeus Sandbox (but add the missing options such as leg durations, total durations etc; yes -- i know this requires turning on extra features per company, but this could be solved by addig checks and conditions).
All the XSD:s etc would still be needed, one would still need to set everything up etc but when done one could simply opt for using the simpler interface for more rapid development on the frontend.
The current problem with the Amadeus SOAP API as a whole is that it requires extensive knowledge about Amadeus specifics (not coding specifics, standards or anything like that -- Amadeus specifics that is more or less only specific to Amadeus SOAP API). This is downright painful for any new developer without prior knowledge of the Amadeus SOAP API. This client is/will smooth such things out which is great, but i think it could do it even better by offering simpler gateways (REST API's) on top of other functions.
I completely understand your reasoning. And from the standpoint of a developer not familiar with Amadeus and needing to make an online booking engine, it makes complete sense.
However, my usecases for using the Amadeus Web Services are often robotic jobs performing checks on PNR's or automating certain workflows of travel agencies working with Amadeus. I need to stay much closer to the Amadeus logic for these kinds of things.
So I'm not sure how we can combine both of these uses in one codebase.
Maybe it would be best to build a simplified REST API on top of this library, and keep this library with all its Amadeus SOAP-specific complexities as it is. But if I have to be honest, I don't think I can spend the necessary amount of time on such a task right now.
Thanks for the very quick reply!
I understand and appreciate that it isn't a priority and something that this project is striving for. As you said, and as i mentioned, it would be better to build these REST API's on top of the library and keep it somewhat separate. But anyway -- thanks for the reply.
Hi DerMika,
for XSD to PHP classes, I usually use this https://github.com/goetas/xsd2php
hope it will help
Thanks. I've used it before, but I've also run into problems with certain XSD's provided by Amadeus. Perhaps I could try again with the latest version...
The one part that takes a lot of time when implementing a new message in the
amadeus-ws-client
is manually having to create all the classes of the request object in theAmadeus\Client\Struct
namespace.It would be ideal - both for our own development as well as for contributors or people who use and extend this client to their own needs - is we could provide an easy way to convert a request XML XSD to a set of PHP classes in the correct namespace which could then be used to generate the correct request message based on the options that were provided.