GET vs POST
When to use GET and when to use POST? a coool explanation is here following are some exerpts:
Rule #1: Use GET for safe actions and POST for unsafe actions.
Rule #2: Use POST when dealing with sensitive data. ( like passwords, so it can’t be seen/bookmarked/used later in urlbar)
Rule #3: Use POST when dealing with long requests.
Although the RFC doesn’t lay down any length-related guidelines, Internet Explorer – with its insistence on finding ways to make things difficult for us – enforces a maximum URL length of 2,048 characters.
Rule #4: Use GET in AJAX environments.
GET requests are more useable:
- GET requests can be cached
- GET requests can remain in the browser history
- GET requests can be bookmarked
- GET requests can be distributed & shared
- GET requests can be hacked
SOAP vs REST
There are a lot of chatter whether to use REST (Learn REST) or SOAP. Simply put, REST is very simple to use (a simple http GET request with https://www.mycompany.com/program/method?Parameters=xx will be enough for REST) and implement. But REST assumes that the connection is point to point (not processed through many servers). it’s rather hard to actually implement REST services to be truly distributed. There comes SOAP with a mandatory POST method and a fat ass data packet. Meanwhile a good read will be WSDL (Web Service Definition Language). a XML based specification for a certain web service, about the url, methods, data, comments.. etc..
To summarize their strengths and weaknesses: (as described in here)
*** SOAP ***
- Langauge, platform, and transport agnostic
- Designed to handle distributed computing environments
- Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
- Built-in error handling (faults)
- Conceptually more difficult, more “heavy-weight” than REST
- More verbose
- Harder to develop, requires tools
*** REST ***
- Language and platform agnostic
- Much simpler to develop than SOAP
- Small learning curve, less reliance on tools
- Concise, no need for additional messaging layer
- Closer in design and philosophy to the Web
- Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries
- Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop (“roll your own”)
- Tied to the HTTP transport model
However, since advent of Web 2.0 (it is the sophisticated name for interactive web movement where users are not only content viewers, but content creators as well), all the applications are becoming RESTful.
Now how to request for a page/service through PHP
naive way: user headers.
but hey, wait. headers *redirects* the page ot the other page. here we are trying to just silently send request to certain web url and get the output back. for this, in php our best bet is curl.
now for a GET request, it’s easy . just a function (not curl. native php)
$result = file_get_contents(http://asd.com/service/method?id=value);
for a post request, easy way is to use curl in php
$ch = curl_init(); curl_setopt($ch, CURLOPT_URL,"http://www.example.com/yourscript.php"); curl_setopt($ch, CURLOPT_HEADER,false); curl_setopt($ch, CURLOPT_POST,true); curl_setopt($ch, CURLOPT_RETURNTRANSFER,true); curl_setopt($ch, CURLOPT_POSTFIELDS, array( 'field1'=>'some date', 'field2'=>'some other data')); $result = curl_exec($ch); curl_close($ch);
for sending data over http, the url needs to be encoded. in php there’s a cool funciton to do that. urlencode.
without the curl library it’s now posible in php to send POST data itself. but that’ll be th enxt post after i try all these stuff to complete my RESTful service for my website!
I will be back people.