I’ve noticed a bug with Magento that affects the code I wrote for the ‘Extending the API’ tutorial so I thought I’d post a fix for it here. Well, I assume it’s a bug since I don’t see how it could be anything else…
Here’s the api.xml file from that tutorial:
<config> <api> <resources> <modulename_category translate="title" module="modulename"> <model>namespace_modulename_model_category_api</model> <title>New Category API</title> <methods> <getID translate="title" module="modulename"> <title>Retrieve Category ID from its name</title> <acl>catalog/category</acl> </getID> </methods> </modulename_category> </resources> <v2> <resources_function_prefix> <modulename_category>catalogCategory</modulename_category> </resources_function_prefix> </v2> </api> </config>
You’ll notice that I declare a ‘resources_function_prefix’ of ‘catalogCategory’ to fit in with the existing Magento API. this means that my new method called ‘getID’ can be accessed via a soap call to ‘catalogCategoryGetID’. This all seems straightforward… or so I thought.
It appears that during execution of soap calls, that resource prefix is mapped directly to a magento module. Hence, if you have a prefix of ‘catalogCategory’ defined in your module any methods with that prefix will be mapped to your module..including the methods defined in the Magento class we’re overriding with our module. So for all the standard Magento API calls you’ll receive a nice ‘invalid APi path’ error.
The workaround for this is pretty obvious, we need to declare our new methods with a different function prefix and then update the wsi.xml (the wsdl file) accordingly.
This of course means you’ll be accessing your methods with a different prefix than the standard magento one (so something like myModuleCatalogCategoryGetID rather than catalogCategoryGetID) but that’s a small price to pay for it actually, you know, working.