Use POST request to call FRAPI

[marty]

Hi again,

I just set up an Action in FRAPI that seems to work well when I test
it through the admin interface, however, when I tried to run it
through a test site that uses an AJAX POST call to the URL, I don't
seem to be getting any response at all..

From what it seems, all requests to the FRAPI server are actually made
via the GET method, with the "method" setting being passed on as a
parameter of that GET request (e.g. "method=post"). I have to admit
that this is very confusing and that I expected to be able to make
actual POST calls to the server, i.e. using something like

$.ajax({
url: 'http://api.mysite.com/action.json',
type: 'POST',
data: {'id':1},
dataType: 'json',
success: onDataReceived
});

is this possible at all?

Thanks,
Martin

[Clay Hinson]

Martin, 

What you're describing doesn't sound like how FRAPI works. However, it does sound like you have the "Allow cross domain requests" setting unchecked in FRAPI admin. Check on the Configuration page for this setting. Without it, tests like the one you describe will return nothing because the AJAX request was not allowed to run across different domains. 

[Martin Bachwerk]

Hi there,

I actually have cross domain requests allowed in the configuration, so
that shouldn't be it.

Also, what do you mean this is not how FRAPI works? In my mind it's
very confusing when the documentation talks about get, post, etc.
methods, but in the end it's always using GET and the "method" is just
a parameter of that, or?

Cheers

[Martin Bachwerk]

Hi there,

I actually have cross domain requests allowed in the configuration, so that shouldn't be it.

Also, what do you mean this is not how FRAPI works? In my mind it's very confusing when the documentation talks about get, post, etc. methods, but in the end it's always using GET and the "method" is just a parameter of that, or?

Cheers

[David Coallier]

>
> I actually have cross domain requests allowed in the configuration, so
> that shouldn't be it.
>
> Also, what do you mean this is not how FRAPI works? In my mind it's
> very confusing when the documentation talks about get, post, etc.
> methods, but in the end it's always using GET and the "method" is just
> a parameter of that, or?
>

Hi there Martin,

I'm not sure what you mean by in the end it's always using GET. If you
want to test the POST, GET, PUT handling, you can do it by defining a
simple executePost(), executeGet() and executePut() in your action and
then invoking it like:

$> curl -X POST http://api.frapi/actionname -d '' -H 'Accept: application/json'
$> curl http://api.frapi/actionname -H 'Accept: application/xml'
$> curl -X PUT http://api.frapi/actionname -H 'Accept: application/xml' -d ''

If you prefer you can drop by our Dublin office on Barrow street and
I'll give you a walk through :)

--
David Coallier

[marty]

Hey David,

What I was referring to was the tester interface actually inside the
admin area - I noticed that the "method" selected in that interface is
passed on as a GET parameter when running the test, so the tests don't
actually use HTTP POST or anything.

Any reason why my jQuery example shouldn't work though? It returns a
500 error if I point it to some wrong URL on the API server, but
doesn't do anything if I point it to the correct url...

One other thing I'm noticing is that the URL pointing to the /public
FRAPI folder actually returns a 500 error, instead of some basic XML
message as suggested by the documentation - is that outdated
information or is something wrong on my server?

So you have an office here just for FRAPI? Or is that together with
something else? :)

Cheers,
Martin

On Mar 22, 4:56 pm, David Coallier <dav...@php.net> wrote:
> > I actually have cross domain requests allowed in the configuration, so
> > that shouldn't be it.
>
> > Also, what do you mean this is not how FRAPI works? In my mind it's
> > very confusing when the documentation talks about get, post, etc.
> > methods, but in the end it's always using GET and the "method" is just
> > a parameter of that, or?
>
> Hi there Martin,
>
> I'm not sure what you mean by in the end it's always using GET. If you
> want to test the POST, GET, PUT handling, you can do it by defining a
> simple executePost(), executeGet() and executePut() in your action and
> then invoking it like:
>
> $> curl -X POSThttp://api.frapi/actionname-d '' -H 'Accept: application/json'

> $> curlhttp://api.frapi/actionname-H 'Accept: application/xml'
> $> curl -X PUThttp://api.frapi/actionname-H 'Accept: application/xml' -d ''

[marty]

Ooh, I see now that the tester sends a GET request to the admin area's
tester/ajax URL, which presumably runs the appropriate HTTP call..
just need to find that :)

[marty]

I promise this is the last spam :)

So what the tester ajax call does is send the data to a PHP file which
runs the appropriate get/post call.. fine..

But what if I want my ajax call to go directly to the API as shown
above - that's the only bit that ain't working right now.

Also, connected to the public homepage not showing an XML message, it
seems that i _have_ to add ".json" at the end of my actionname for
anything to work - I have JSON set to default in my settings, so I
would have imagined that it should work without that as well, or?

Thanks so much :)

[marty]

And the fix: Chrome showed that my AJAX call was raising the following
error: "Request header field X-Requested-With is not allowed by Access-
Control-Allow-Headers" (Firebug didn't show this, boo-hoo!). Updating
jQuery to 1.5.2 solved that. *yay* :)