from http://stackoverflow.com/questions/16329191/using-amazon-mws-inventory-api-with-codeigniter-php
Thank you,
I) Write a model from scratch
New code accessing the MWS would mostly end up in the "Model" space. The controllers and views (which you'll probably eventually need) are outside the scope of the code that Amazon provides, so they need to be written anyways. As far as the MVC (and OOP) idea goes, this is the "proper" way to do it, you can make full use of inheritance and polymorphism.
Advantages: Your model accessing the MWS will follow the rules and guidelines of your MVC framework. It will be easy to integrate into other parts of the framework, and integrate nicely with the rest of the code.
Disadvantages: lots of code to write and (more importantly, since MWS is a moving target) maintain.
II) Use Amazon's code as a library
Amazon's code would go into the "Libraries" space. As it doesn't follow the rules of your MVC framework, it will "feel" foreign to the rest of the code.
Advantages: Less code to write and maintain.
Disadvantages: No usage of the framework, no code reuse, no inheritance and no polymorphism.
III) Write a wrapper
This is basically a mix of the two options above. You write a very thin wrapper around the library (goes into the Model space) which calls the unmodified Amazon library. Written properly, you might get a "best of both worlds" - this depends on how much the interface the library matches your desired model interface.
Advantages: Often only little extra code is needed, when compared to the "library" approach", while the model can be used in the same way as a complete rewrite.
Disadvantages: Sometimes needs almost as much code as writing from scratch.
Suggestions and Comments
My approach would probably be to go with a wrapper, unless I need just a fraction of the library's code. Since PHP does not have a strict object hierarchy, it is usually possibly to properly mimic inheritance anyways if needed.
A side note on designing a model around the MWS: Unlike most web services, some calls to the MWS API (e.g. SubmitFeed) work asynchronously in that information about the success or failure of an operation will only be available minutes (or even hours) after the call has been made. Most MVC model hierarchies and interfaces are not designed to handle that type of thing well, so a complete rewrite might not give you the benefits that you'd normally get.