Making use of XML-RPC /REST or Other webservice(Desktop application)

Is there a way, with MODx that one can authenticate using an external application? Even a desktop application?

EDIT:
I’ve made the subject more descriptive

Quote from: designetic at Nov 10, 2010, 10:56 AM

Is there a way, with MODx that one can authenticate using an external application? Even a desktop application?

Sure, but I think you need to better explain what you mean. Do you mean to access the core of MODx, or do you mean custom web services you are building via Snippets/Resources?

sorry for being vague. I posted in a hurry.

To be clear, I would like to create a desktop application(for a ModX website) that allows a registered user to be authenticated and to receive information on that website.

I assumed the best way would be via a web service. I have never done this before, so please excuse my ignorance. I assume that the desktop application will send the username and password to the website through some webservice(interface) then once authenticated, the user can download the content.

Or am I being ambitious with the current ModX functionality?

Quote from: designetic at Nov 11, 2010, 09:47 AM

sorry for being vague. I posted in a hurry.

To be clear, I would like to create a desktop application(for a ModX website) that allows a registered user to be authenticated and to receive information on that website.

I assumed the best way would be via a web service. I have never done this before, so please excuse my ignorance. I assume that the desktop application will send the username and password to the website through some webservice(interface) then once authenticated, the user can download the content.

Or am I being ambitious with the current ModX functionality?

You’ll need to expose the web services into the core MODx processors for login and whatever other actions you want them to be able to take, but the central system of core processors is intended to be exposed that way, so you are not necessarily being too ambitious. Then again, ambition is good, mmmmkay?

Quote from: OpenGeek at Nov 11, 2010, 12:08 PM

Quote from: designetic at Nov 11, 2010, 09:47 AM

sorry for being vague. I posted in a hurry.

To be clear, I would like to create a desktop application(for a ModX website) that allows a registered user to be authenticated and to receive information on that website.

I assumed the best way would be via a web service. I have never done this before, so please excuse my ignorance. I assume that the desktop application will send the username and password to the website through some webservice(interface) then once authenticated, the user can download the content.

Or am I being ambitious with the current ModX functionality?

You’ll need to expose the web services into the core MODx processors for login and whatever other actions you want them to be able to take, but the central system of core processors is intended to be exposed that way, so you are not necessarily being too ambitious. Then again, ambition is good, mmmmkay?

thanks for the helpul info.

Now I come to my last question. It has been a long time since I’ve touched MODx. I havent dug into the Revolution code and I have some custom snippets or modules would like to use for this project.

1)Is there any documentation/example code on XML-RPC with MODx?
2)Is Evo as secure as Revo in XML-RPC related use?
3)Will my modules that worked in 0.9.6.3 work just as well on Evo?

If you want examples of how to talk to the back end processors in Revolution have a look at the Provisioner package, this uses CURL requests to interrogate and retrieve information from a remote Revolution site such as resource/element listings etc.

The data returned is in JSON format as expected by the manager and can be interpreted and drawn any way you wish in the front end, what you are actually doing is replacing the MODx manager with whatever front end app you like, mobile, desktop etc.

There’s no docs at the mo for the API here(that I know of), you need to look at the code in /core/model/modx/processors, also you will need the site API key of any remote site you wish to talk to.

Another way to do this is to write your own API(XML-RPC/JSON whatever) that transforms your front end requests into calls to the MODx processors using the executeProcessor method, if you find the processors don’t do exactly what you want you can of course drop into code/XPDO calls to do what you wish.

The first method has the advantage that its already done for you, as long as you can do what you need with the existing API, the second is much more flexible as you create the API but obviously there is more effort involved here in coding/testing etc.

I would suggest that if you were to chose the second method to try and write a general API interface that can be used by others, this can then be packaged and maintained as single code base.

Quote from: shamblett at Nov 12, 2010, 02:44 AM

If you want examples of how to talk to the back end processors in Revolution have a look at the Provisioner package, this uses CURL requests to interrogate and retrieve information from a remote Revolution site such as resource/element listings etc.

The data returned is in JSON format as expected by the manager and can be interpreted and drawn any way you wish in the front end, what you are actually doing is replacing the MODx manager with whatever front end app you like, mobile, desktop etc.

There’s no docs at the mo for the API here(that I know of), you need to look at the code in /core/model/modx/processors, also you will need the site API key of any remote site you wish to talk to.

Another way to do this is to write your own API(XML-RPC/JSON whatever) that transforms your front end requests into calls to the MODx processors using the executeProcessor method, if you find the processors don’t do exactly what you want you can of course drop into code/XPDO calls to do what you wish.

The first method has the advantage that its already done for you, as long as you can do what you need with the existing API, the second is much more flexible as you create the API but obviously there is more effort involved here in coding/testing etc.

I would suggest that if you were to chose the second method to try and write a general API interface that can be used by others, this can then be packaged and maintained as single code base.

thanks, shamblet, will definitely look at the Provisioner.

So is it safe to conclude that the XML-RPC implementations are the same for both Revo and Evo? None is a better choice than the other?

As a side note:
Am I the only one who has to constantly go back to the home page to remind myself which one is Revo and which is Evo? The names are similar, I get a lil confused. No biggie anyways!

Your XML-RPC interface will be the same in both cases, say you have a call(or calls) to get a list of resources created by user fred in the last day, this will be the same call as far as your front end widget is concerned whether to a Revo or Evo install, its the back end that will differ, Revo has processor execution, XPDO etc, Evo, has straight mysql calls and the like. Both products will support your interface in their own different ways, if you want a ’better choice’ then Revo is the way to go here IMHO.

thanks shambert. will see whether i’ll opt for Revo but I think I’ll go Evo for now.

Hopefully reading Provisioner code will give me more insight.