cURL questions

[SecondCity]

I am still struggling to completely understand cURL.

 

1.) Can a cURL statement(s) be both a POST request and a GET request at the same time?

 

 

2.) I believe this code force a POST, right?

 

curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml->asXML());

 

 

3.) I believe this forces a GET, right?

 

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

 

 

 

[benanamen]

REQUEST includes both GET, POST, and COOKIE. Not sure if it relates to cURL though.

http://php.net/manual/en/reserved.variables.request.php

 

I know that cURL supports 

• DELETE
• GET
• POST
• PUT

Edited April 13, 2017 by benanamen

[Jacques1]

1.) Can a cURL statement(s) be both a POST request and a GET request at the same time?

 

No, and this has nothing to do with cURL. An HTTP request has exactly one method which defines the semantics. GET is for fetching a resource, POST is for adding or changing a resource.

 

 

 

2.) I believe this code force a POST, right?

 

Yes. Just like the manual says.

 

 

 

3.) I believe this forces a GET, right?

 

The default method is GET, yes.

[SecondCity]

No, and this has nothing to do with cURL. An HTTP request has exactly one method which defines the semantics. GET is for fetching a resource, POST is for adding or changing a resource.

 

 

 

 

Yes. Just like the manual says.

 

 

 

 

The default method is GET, yes.

 

 

Not sure I understood your response...

 

I was asking if these 3 lines were together, would it be both a POST and then a GET?

 

 

curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml->asXML());
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

[Jacques1]

No. As I already said, a request has exactly one method. One. So it's either GET or POST. Both at the same time is impossible and nonsensical, regardless of any code.

 

The default method in cURL is GET. But when you explicitly enable CURLOPT_POST, then you get POST instead. So your above code triggers a POST request.

 

CURLOPT_RETURNTRANSFER has nothing to do with GET or any method. As you might guess from the name, it makes cURL return the response rather than printing it directly (which is the default behavior).

 

It's really not that hard to understand, especially if you RTFM. Every single option is documented, so there's no need to guess what they mean.

[SecondCity]

No. As I already said, a request has exactly one method. One. So it's either GET or POST. Both at the same time is impossible and nonsensical, regardless of any code.

 

The default method in cURL is GET. But when you explicitly enable CURLOPT_POST, then you get POST instead. So your above code triggers a POST request.

 

CURLOPT_RETURNTRANSFER has nothing to do with GET or any method. As you might guess from the name, it makes cURL return the response rather than printing it directly (which is the default behavior).

 

It's really not that hard to understand, especially if you RTFM. Every single option is documented, so there's no need to guess what they mean.

 

I did RTFM and yet I still have questions.

 

If you can't be civil then don't respond.

[Jacques1]

If a simple RTFM already hurts your feelings, then you will struggle in the IT world.

 

I've answered your questions. Now stop complaining.

[SecondCity]

The abbreviated code above is supposed to submit a request to the payment gateway.

 

From RTFM, these lines of code should be doing that...

curl_setopt($ch, CURLOPT_URL, $url); // Provide the URL to use in the Request.
curl_setopt($ch, CURLOPT_POST, 1); // Peform a POST transaction.
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml->asXML()); // Specify XML template/data to POST in the Request.

However, when I run the sample code my payment gateway gave me, I am also getting a response back!

 

I know this because of this code...

$xml_response = curl_exec($ch);
 
var_dump($xml_response);

So, after RTFM, but still not knowing how any of this works, it would appear that the combination of...

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

and running

$xml_response = curl_exec($ch);

 

give me response to my original request.

 

 

Then again, it is unclear from RTFM if I get a response because my payment gateway is sending one out to me after they get my request, OR if because this code somehow triggers a response...

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$xml_response = curl_exec($ch);

 

 

If you are new to cURL and XML and payment gateways, then all of this is NOT OBVIOUS, and RTFM is asinine advice, because it doesn't necessarily explain the larger concept!

 

Edited April 14, 2017 by SecondCity

[Jacques1]

The real problem is that you don't seem to understand the HTTP protocol, so maybe you should start with that before you worry about cURL.

 

In HTTP, a request is always followed by a response. Always. So no matter which method you choose, you will get a response (unless the server crashes, the connection collapses, ...).

 

If the response doesn't contain any useful data, just ignore it (but do check the response code to detect errors).

[SecondCity]

The real problem is that you don't seem to understand the HTTP protocol, so maybe you should start with that before you worry about cURL.

 

In HTTP, a request is always followed by a response. Always. So no matter which method you choose, you will get a response (unless the server crashes, the connection collapses, ...).

 

If the response doesn't contain any useful data, just ignore it (but do check the response code to detect errors).

 

 

I did take your advice from an earlier thread and read up on HTTP, but like everything, it is a gradual learning curve.

 

And I missed that that you *always* get a response when you send a request with HTTP.

 

Either way, earlier I was talking about my payment gateway's use of the term "request" and "response" and didn't assume they meant the same thing as what you are referring to.

 

 

In my op, I was confused by the sample cURL they provided, because this code seems to make a POST...

 

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml->asXML());

 

 

While this code seems to make a GET...

 

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

 

You wouldn't use that line of code if you were purely POSTing data, right?  (The examples I have seen online use this line when you use cURL to GET a webpage.)

 

 

Not getting any support from the payment gateway, I figured I would use one request using cURL to POST my credit card details to them, and then I would make a second request using cURL to GET the results from my initial submittal.

 

Maybe that isn't how it works, and that is what I am trying to figure out on my own!

 

Hope that makes more sense.

[Jacques1]

Again: The CURLOPT_RETURNTRANSFER option has nothing to do with GET or POST. It tells cURL to either print the response (the option is disabled, which is the default) or return it (the option is enabled) So omitting the line makes cURL print anything which comes back from the server, and I'm pretty sure that's not what you want.

 

When you communicate with an API, you have to do exactly what the API expects from you. Inventing your own procedures is not an option. Even if you manage to make it “work”, there's a huge risk of causing problems, maybe in non-obvious ways. You said you get no support from the payment provider, but surely there's a technical documentation somewhere. This is about money, so the provider certainly doesn't want its customers to use the service in a trial-and-error fashion. Get the documentation, read it carefully and then implement your client script according to the rules.

 

I'm not sure why you've been given this task when you have no experience with HTTP, XML, cURL or any other of the involved technologies. But if there's no way around it, looks like that's what you have to do.

[SecondCity]

Again: The CURLOPT_RETURNTRANSFER option has nothing to do with GET or POST. It tells cURL to either print the response (the option is disabled, which is the default) or return it (the option is enabled) So omitting the line makes cURL print anything which comes back from the server, and I'm pretty sure that's not what you want.

 

When you communicate with an API, you have to do exactly what the API expects from you. Inventing your own procedures is not an option. Even if you manage to make it “work”, there's a huge risk of causing problems, maybe in non-obvious ways. You said you get no support from the payment provider, but surely there's a technical documentation somewhere. This is about money, so the provider certainly doesn't want its customers to use the service in a trial-and-error fashion. Get the documentation, read it carefully and then implement your client script according to the rules.

 

I'm not sure why you've been given this task when you have no experience with HTTP, XML, cURL or any other of the involved technologies. But if there's no way around it, looks like that's what you have to do.

 

I thought CURLOPT_RETURNTRANSFER was more associated with a GET request.

 

Now that you are saying for each request there is a response, then I guess I can see how CURLOPT_RETURNTRANSFER could relate to a POST as well.  (I thought when I POSTed credit card data to the payment gateway that request was a one-way street, so you wouldn't care about formatting a response since there wouldn't be one.  I now see the ways of errors.)

 

I'm not inventing anything, just working with a crappy code example that is incomplete, along with an API manual that leaves a llot to be desired as well.  (I have spent all week RTFM for both PHP and cURL and the API, although clearly I am no expert yet.)

 

Late yesterday I was able to determine that I was getting a response back from the API, but then I ran into trouble formatting it into a way that I could read it.  I was getting this long cryptic string...

 

If I can figure out how to parse/format the returned string, I may be getting closer to a working solution.