CiviCRM Community Forums (archive)

Annudit  -

Re git -I think you need to push your hacks to the osdi & rest files to github as a second git repo. It doesn't really reflect a true repo (i.e it's probably not the final location for the work you are doing) but it will make it visible.

Problem statment
I think this is your problem:
When I click on the link from the AEP page I see the link to people as

http://camus.fuzion.co.nz/hal-browser/browser.html#http://camus.fuzion.co.nz/hal-browser/browser.html#/sites/all/modules/civicrm/extern/osdi.php?entity=People&action=get

instead of
http://camus.fuzion.co.nz/hal-browser/browser.html#http://camus.fuzion.co.nz/sites/all/modules/civicrm/extern/osdi.php?entity=People&action=get

or
http://camus.fuzion.co.nz/hal-browser/browser.html#/sites/all/modules/civicrm/extern/osdi.php?entity=People&action=get

Other examples

On the opensupporter example I see
http://api.opensupporter.org/hb2/browser.html#http://api.opensupporter.org/api/v1/people


Looking at the HAL github code they return a format for links like
{
    "_links": {
        "self": { "href": "/orders" },
        "next": { "href": "/orders?page=2" }
    }
}

So, there are variations in the above 2 as to whether the _links section is returning relative or non-relative & the presence of question marks in the url. What variations have you tried returning from your AEP code?

If you can't hit a variation that works it might be time to reverse engineer the transformation going on in the HAL browser in this bit of code.

https://github.com/mikekelly/hal-browser/blob/master/browser.html#L65

So, you have replaced the php file you previously had in osdi.php with a flat file in order to try out variants of the links?

I stuck up a file next to your files on camus

http://camus.fuzion.co.nz/hal-browser/browser.html#/sites/all/modules/civicrm/extern/osdie.php?entity=People&action=get

& it seems to be moving to relative urls ok - but of course - there is nothing to retrieve because the file you had earlier to return results is not there at the moment from what I can tell

OK - so is the plan that the osdi.php will have php code in it, much like rest.php that takes the parameters out of the url & calls your api appropriately (or returns AEP data if no entity is specified) & ensures the results are formatted correctly?

Or were you planning on redirecting the browser to a different url?

Great - looking forward to seeing what you get done today. & yes, the osdi.php file would return the json you mention, as appropriate

I think it makes sense to call the api from the osdi.php as that is the access point. You can copy rest.php for code to help get civi initialized from that file. OSDI.php is kindof the osdi equivalent to rest.php. If you instantiate CiviCRM  in there you will be able to call your api calls using php in there.


Then the actual api can sit in your extension & osdi.php can provide the wrapper

Anudit, thanks, great to see progress.

Updates:

In today's meeting on IRC with Joe McLaughlin and Eileen I discussed about setting options to provide limit for returning maximum number of records also since I had change the name of my custom extension on the camus server because of which the REST URL for retrieving the people's record was not working, so we discussed on fixing that as well. Also I had an email conversation with Jason Rosenbaum from Action Network, I discussed with him about PHP library I was working with so he advised me to go ahead with it as they also use ruby/rails library for achieving the same result as on OSDI's API sample page.

Today I worked on my previously specified target, now I am able to generate the People endpoint page with all the individual person's data presented at respective OSDI specified fields.
I have updated the code on my repo here https://github.com/anuditverma/OSDI-Implementation/blob/master/api/v3/People/index.php

Eileen-  The code is working fine on my local machine as I have made no changes till now as I did on the camus by changing the name of the custom extension. So I backed up my API files present in the extension, uninstalled & deleted it and created a new one with

civix generate:module osdi –license=AGPL-3.0
but it throws an error Malformed package name
this is because it follows fully qualified extension names as per the documentation.

Also I tried replacing instances of org.civicrm.osdi to osdi but some of the php files contains functions which had their names based on fully qualified extension name.

These changes are required for proper functioning of the extension and also because I run my development environment on Apache whereas on the camus it runs on nginx so certainly it won't be working the same. So if you could make some changes in the server configuration of camus so that I need not to modify (for eg custom extension's name by removing dots in between) my custom extension in future as well or from now onwards if I can follow some conventions in the development process primarily for nginx.

Meanwhile I am also trying if I can achieve the same results on the camus as I am getting locally.

Thank you.