Jump to content

cURL questions


SecondCity

Recommended Posts

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);
 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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);
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites


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!

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.