When designing client libraries to send data to our API, one of our top priorities is to make sure that none of our code affects the performance of your core application. That is tricky when you have a single-threaded, "shared-nothing" language like PHP. [...] Ideally, we like to keep the setup process minimal and address a wide variety of use cases. As long as it runs with PHP (and possibly a common script or two), you should be ready to dive right in. We ended up experimenting with three main approaches to make requests in PHP. Here's what we learned.

Their three suggestions don't involve external dependencies (like a queue server) and can operate pretty quickly:

• Opening a socket and closing it before waiting for a response
• Write to a log file (a pseudo-queue)
• Fork a curl process (through something like exec)

They each have small code examples included with them and explanations as to their plusses and minuses. For their needs, the "forked curl" solution worked out the best, but check out the other options too - you might have different needs.

Good tools are invaluable in figuring out where problems lie, and can also help to prevent problems from occurring in the first place, or just help you to be more efficient in general. Command line tools are particularly useful because they lend themselves well to automation and scripting, where they can be combined and reused in all sorts of different ways. Here we cover six particularly powerful and versatile tools which can help make your life a little bit easier.

The tools they mention are all things you'd install on a unix-based system:

• Curl
• Ngrep (network packet searching)
• Netcat (to work with network connections)
• Sshuttle (SSH tunneling)
• Siege (HTTP benchmarking)
• Mitmproxy (capturing proxy, both HTTP and HTTPS)

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

Lately I've been playing around with the CloudVPS ObjectStore, which is currently in beta phase. This blogpost shows the options of this ObjectStore in a practical way and concludes with a summary of commands you can use yourself to interact with it and some ideas. For this post, I assume you are familiar with cURL, REST and HTTP headers.

He shows how to make the requests for:

• Authentication
• Working with containers
• Adding files to a container
• Setting access permissions

Nowadays there is a header to allow it: Access-Control-Allow-Origin. The problem is that the remote server must set up this header. For example I was playing with github's API and github doesn't have this header. If the server is my server, is pretty straightforward to put this header but obviously I'm not the sysadmin of github, so I cannot do it. What the solution? One possible solution is, for example, create a proxy server at localhost with PHP.

He shares the full code for his project - basically a handler that takes the incoming request and mirrors to out to the public, remote API - request method and all. It uses some of the packages from Symfony (like the http-foundation) and wraps around cURL to handle the requests. The project is available for Composer users as well.

Checking Deadlinks From the database manually is a Headache ,So why not use a script which return the http status of the particular link and tell us if the link is dead or not.So how do we check the dead links from the database ? How do we programatically check whether the link is dead or not ? To check broken or dead links from Database we will use curl .

Included in the post is a sample script that extracts the URLs from a field in the database (you'd need some extra smarts if you're pulling it from content) and running it though a "checklink" function. If the call to curl_getinfo returns false, the link is marked dead.

Imagine it's a warm, sunny, summer day. You're just walking along, taking a leisurely noonday stroll, when all of a sudden you come face to face with a RESTful API. What do you do? How do you interface with it? Or, as those of us in the know would say, "how do you consume RESTful services?" That, my friends, is the subject of this article.

They mention using other tools (like components/features of common frameworks) to interface with the services, but end up using the curl extension to make a POST request to a service to add a few events to a "/summerschedule" resource.

Here is the technique to get the detail of the Facebook page with Graph API and PHP. This is the very easy method to get the Facebook page detail. So Let's see how to get this done. With this method you can get details of any Facebook page [inluding] name, picture, link, website, products, description and if the user can post to it.

The sample code is only a few lines - it uses the Facebook page ID (easy to grab from the URL) and fetches a URL with it as a parameter. The output is returned as a standard PHP object with all of the properties attached (decoded from JSON). This is just one of many methods the Facebook graph API has, so check out their documentation for more methods and details on returned values.

We can't send post fields, because we want to send JSON, not pretend to be a form (the merits of an API which accepts POST requests with data in form-format is an interesting debate). Instead, we create the correct JSON data, set that as the body of the POST request, and also set the headers correctly so that the server that receives this request will understand what we sent.

She includes a code example (about ten lines) showing the POSTing process that sets up options using curl's curl_setopt. Be sure to set up the headers to send as "application/json" - that's the trick to letting the remote end know the format.

Tonight I decided to relax a bit and what better way of relaxing is there for a geek then to do some bash scripting?! So for fun and no profit I decided to try and benchmark pages with ab, Apache HTTP server benchmarking tool, which are behind a login. Turns out, it's pretty easy after reading some man pages.

He includes an example of the format of the "cookie jar" and the shell script he used to grab the PHP session ID from it and inject it into the "ab" call. The script is on github.