Lots
of APIs support session-based authentication. In these schemes, the
user first has to call a “login” method which takes the username and
password as input and returns a unique session key. The user must
include the session key in each request, and call “logout” when they are
done. This way, authentication is kept to a single pair of API calls
and everything else is based on the session.

This type of
authentication maps very naturally to a web site, because users are used
to “logging in” when they start working with a particular site and
“logging out” when they are done.

However, session-based
authentication is much more complex when associated with an API. It
requires that the API client keep track of state, and depending on the
type of client that can be anything from painful to impossible.
Session-based authentication, among other things, makes your API less
“RESTful” - an API client can’t just make one HTTP request, but now a
minimum of three.

The Role of OAuth

Today, many APIs also support OAuth
authentication. OAuth was designed to solve the
application-to-application security problem. The idea of OAuth is that
it gives the user of a service or web site a way to conditionally grant
access to another application. OAuth makes it possible for a human user
to individually grant other APIs or sites access to their account
without sharing their actual password. It works by giving a “token” to
each API or site that will access the account, which the user may revoke
at any time they wish.

For instance, if web site FooBar.com wants access to the Twitter API
on behalf of John Smith, then OAuth specifies the protocol that
FooBar.com must go through to get an OAuth token for the Twitter API.
Part of this process requires John Smith to log in to his Twitter
account using his normal username and password (which, in the OAuth
protocol, are never seen by FooBar.com) and authorize FooBar to access
his account. The result is that FooBar.com will have an OAuth token that
gives it access to John Smith’s account. If, later on, John Smith
decides he no longer trusts FooBar.com, he has the option to revoke that
OAuth token without affecting his regular password or any other
accounts.

This process makes OAuth the ideal for communication from one
application to another – for instance, allowing MySpace to post photos
to your Twitter account without requiring that you enter your Twitter
password every time you want to do it – but it can be used for any kind
of API communications as well.

Two-Way SSL, X.509, SAML, WS-Security...

Once
we leave the world of “plain HTTP” we encounter many other ways of
authentication, from SAML, X.509 certificates and two-way SSL, which are
based on secure distribution of public keys to individual clients, to
the various WS-Security specifications, which build upon SOAP to
provide... well, just about everything.

An API that will primarily be used by “enterprise” customers – that
is, big IT organizations – might consider these other authentication
mechanisms such as an. X.509 certificate or SAML for more assurance over
authentication process than a simple username/password. Also, a large
enterprise may have an easier time accessing an API written to the SOAP
standard because those tools can import a WSDL file and generate an API
client in a few minutes.

The idea is to know your audience.
If your audience is a fan of SOAP and WSDL, then consider some of the
more SOAP-y authentication mechanisms like SAML and the various
WS-Security specifications. (And if you have no idea what I’m talking
about, then your audience probably isn’t in that category!)

Rolling Your Own

In
between OAuth, HTTP Basic, and the basic API key are many alternatives.
It seems that there are as many other API authentication schemes as
there are APIs. Amazon Web Services, Facebook, and some Google APIs, for
instance, are some big APIs that combine an API key with both public
and secret data, usually through some sort of encryption code, to
generate a secure token for each request.

The issue – every new authentication scheme requires API clients to
implement it. On the other hand, OAuth and HTTP Basic authentication are
already supported by many tools. The big guys may be able to get away
with defining their own authentication standards but it’s tough for
every API to do things its own way.

SSL

Most
authentication parameters are useless, or even dangerous, without SSL.
For instance, in “HTTP Basic” authentication the API must be able to see
the password the client used, so the password is encoded – but not
encrypted – in a format called “base 64.” It’s easy turn this back into
the real password. The antidote to this is to use SSL to encrypt
everything sent between client and server. This is usually easy to do
and does not add as much of a performance penalty as people often think.
(With Apigee’s products, we see a 10-15 percent drop in throughput when we add SSL encryption.)

Some security schemes, such as OAuth, are designed to be resistant to
eavesdropping. For instance, OAuth includes a “nonce” on each request,
so that even if a client intercepts an OAuth token on one request, they
cannot use it on the next. Still, there is likely other sensitive
information in the request as well.

In general, if your API does not use SSL it also potentially exposes everything that your API does.

I know it’s fashionable to mock PHP for its antiquated syntax and semantic quirks, but I just like it. Here is why.

PHP is like C

This is really the main point of this post, and it’s a realization so simple that I’m surprised not more people made it. I have often observed that developers mocking PHP tend to be much more positive when I ask them about C.

“C is alright, it’s not OO but it was designed with a simple goal in mind and it does that very well. It’s straightforward and very well documented”.

Does that remind you of another language? That’s right, PHP! PHP is exactly like C. Either you like both or you don’t like either, there is no claim you can make about PHP that can’t be made about C as well, and vice versa. PHP was created with one very simple goal in mind: enabling the insertion of programming logic in web pages. And it does this fantastically well.

The absence of OO functionalities in both languages is a bit of a bummer (PHP 5 tried to address that with mixed success), but with some discipline, it’s really not hard to reach a reasonable architecture for your programs.

PHP never let me down

I write PHP code very sporadically, whenever I need to update one of my web sites or when I need to put together a small piece of web functionality that requires some programming. I am familiar with the PHP syntax but I don’t know much of its API, because I use it so rarely, so I pretty much need to relearn it from scratch each time. Whenever I need to get something done, I spend a decent amount of that time looking up docs on Google. And PHP absolutely shines in this area. It’s not just that looking up a function name will give you its API documentation as a first hit, but you can literally type what you need in English (e.g “most recent file in PHP”) and it’s very likely that you will find how to do it in just a few clicks.

You can even misspell function names (see for example the result of my incorrect query for strtime) and you will still land in the right place.

PHP is robust

I know it sounds silly considering how primitive and old the language is, but the bottom line is that code that I wrote more than ten years ago has been working absolutely flawlessly and without any changes for all that time. I don’t even bother writing tests for most of the PHP I write (obviously, I would be a bit more thorough if this code were destined to be used in a more mission critical web site). Not writing tests is not the only software taboo that I break when I write PHP: I happily mix up presentation and logic all the time. That’s just how PHP is supposed to work, and when the site you are working on is low volume and only of interest to a very tiny fraction of users, you probably don’t want to spend too much time on tasks that look overkill.

PHP’s documentation is great

It’s hard to pinpoint what exactly makes PHP’s online documentation so useful. It’s probably a mix of the content, the syntactically colored code samples, the CSS and most of all, the examples at the bottom. These are absolutely priceless and I don’t understand why not all API documentations do this.

Whether you are looking up an API function or a UNIX command, the first thing you want to see is examples, not a laundry list of its options and switches or a formal definition of its parameters. Very often, reading the example is all you need to carry on with your work and you can always read the more formal documentation if you want to use the function in a more advanced manner.

Universal support

Most Internet providers offer PHP support out of the box, so you don’t need to resort to more expensive VPS providers. I have yet to see this kind of universal support for any other language than PHP. Not even Ruby on Rails, let alone Java, is available on mainstream providers, thereby validating the claim I made five years ago that Ruby on Rails won’t become mainstream (I regularly receive emails about this article asking me this question, and I keep responding “Nope, still not mainstream”).

High reward

There is nothing more exciting than modifying a file, hitting Refresh on your browser and seeing the result right away. This brings me back to the very first days that I started experimenting with a web browser, more than fifteen years ago. Modifying an HTML file and seeing the result almost instantly hasn’t lost its appeal, and PHP is certainly continuing the tradition.

Sometimes, I don’t even bother editing the files locally and then transferring them: I ssh to my server and modify the files live. If something goes wrong, git makes sure that I can always back up my changes very easily. By the way, the combination of git’s branches and PHP is very powerful, allowing you to switch between entire web sites with just one command.

Conclusion

Even though writing in PHP always feels like going back in time, I’m never reluctant to doing it because I know that it will be rewarding and relatively easy. PHP has by far the highest “Get in, code, get out” factor that I have found in a language, and until another language comes around that can do better on this scale, I will be using PHP for many more years to come.

5. PHP is controlled by only one company (Zend)

6. PHP documentation is bad or insufficient

7. PHP projects are not reusable because they are not Object Oriented

9. PHP is not good for high performance scalable Web sites or applications

10. PHP developers are cheaper because they are not qualified

Other Wrong Ideas About PHP

Introduction

Recently I found an article in the DZone site titled I like PHP by Cedric Beust. Actually it is a repost of the original article published first on Cedric's own blog.

The article got my attention for several reasons. One of them is the fact that the article is written by a Java fan and was reposted on a section of the DZone site called Java Lobby. It is a bit surprising finding such type of confession from a Java fan.

I like this article not merely because it praises some important aspects about PHP but rather because it is mostly accurate. That is another reason why the article got my attention.

In the article certain PHP features are highlighted by a developer that is fan of another language. Probably he hoped that Java provides those PHP features. At least while Java does not provide those features, he says he will be enjoying PHP as well. Good for him for being open minded.

Anyway, the main reason why I decided to write this post is not so much about that article, but rather about a comment found below in the DZone article page by somebody named Matt Young.

Matt goes on contesting some of the claims of the article. Most of his arguments are inaccurate, just to put it nicely. To be quite frank most of those arguments are just common plain wrong ideas that many people have about PHP.

I have seen many of those arguments over and over again being spread by PHP haters. Actually the fact that there are developers that hate PHP with a passion feels very odd to me. Not that I mind people bothering to hate PHP. It seems to me that they are losing so many opportunities that PHP provides to millions of developers that do not have such hard feelings.

Therefore I decided to write this article with the intention of helping those haters to see PHP from a more positive side that even they can take advantage.

I am sure I will not be able to convince those that are so obcessed in campaigning against PHP because they are extreme fans of other languages. I hope at least I can provide useful information to those that are willing to help contesting those wrong ideas about PHP, so PHP gets more respect from people that were mislead into believing in those wrong ideas.

Top 10 Wrong Ideas About PHP

Here follows a list of some of more common wrong ideas about PHP. I just presented the top 10 that I find more relevant, but I could have even listed more. It is that 10 is just round number that people are used to find more frequently in top listings. :-)

1. PHP is not a compiled language (it is interpreted)

First let me get a bit more technical to explain what this means. A compiled language is one that needs to convert source code in that language into a sort of machine code before it can be executed. An interpreted language is one that allows its code to be executed directly from the source text without a compilation step (convert source text into executable machine code).

PHP is not an interpreted language since PHP 4, which was launched in the year 2000. It is not the first time that I cover this subject in this blog. Previously I have written a popular article about PHP compiler engines performance. Let me just stick to the essential concepts that matter to clarify this subject.

When a PHP script is executed, first the PHP source code is compiled by the Zend engine into machine code data named Zend opcodes. These opcodes are stored in the RAM. Then those opcodes are executed to actually run the script.

So PHP is really a compiled language just like Java, C# and others. Otherwise it would be rather slow.

Usually the compiled PHP machine code (Zend opcodes) are not saved to files because it is not necessary. But if that is important to you, there are extensions that can output compiled PHP code to files.

By default, if you run the same script again, PHP source code needs to be recompiled into the RAM every time it is executed. However, there several opcode caching extensions that can save the compiled PHP opcodes to shared memory, so next time a PHP script executed for a different Web server request, the original source no longer needs to be recompiled. It is just loaded from shared memory, thus saving a lot of processing time.

The use of an opcode cache extension is thorougly recommended for performance reasons, especially on busy sites. There are several free opcode caching extensions that you can use.

So, as you may understand by now, the PHP code execution engine is quite sophisticated these days. But if you need something even more sophisticated, there is the HipHop for PHP compiler. This is an Open Source project developed by Facebook to take the PHP performance to the extreme. It compiles PHP source code into C++, which is then compiled into native machine code into a single Web server binary or a standalone executable program. Facebook uses it to run most of their site.

There are also other PHP compiler projects that convert PHP code into Java bytecodes or .NET assemblies. More details can be found on the PHP compiler performance article already mentioned above.

PHP is an extensible language. If you need something that the main PHP distribution does not implement, you can create PHP extensions, usually by writing some C or C++ code. So PHP can do anything that C or C++ can do.

There are tens, if not hundreds of PHP extensions. Many of them are shipped built-in the main PHP distribution. If you need something that is not built-in PHP, you can always check the PECL PHP extension repository. This is the official repository for less popular PHP extensions written in C or C++ code.

If there is no extension to do something that you need, maybe that is because you have an unusual need. Probably you are addressing a new problem or it is something that nobody else has a need for. So, you can always develop a new extension yourself. If you are not capable of developing C or C++ code, you can always hire another developer to do it for you. So you are never stuck without a solution.

3. PHP cannot do something that can be done in language X

I doubt that there many relevant things that you cannot do in PHP that you can do in other languages. Maybe you can do things in other languages using different programming styles but that does not mean that you cannot develop the same features in PHP, given all the available PHP extensions.

Still, if you find something that can only be done in some other language or you have to rely in existing components written in that language, you can always try to interface with code written in other languages using special PHP extensions available for that purpose.

This is not a very well known fact, probably because it is not something that has great demand, but there PHP extensions that let you execute code in other languages from PHP scripts, like code in: Java, C# (.NET), Python, Perl, Lua, JavaScript using either V8 or SpiderMonkey engines.

Oh, wait, there is no Ruby extension for PHP as you may have noticed. As I said, that is probably because nobody has such an odd need. Still, if you really have that need, maybe you can convert Ruby into Java using JRuby and then you can use the PHP Java extension to run the converted Ruby code. The same goes for other less popular languages.

It is a long shot that may make you wonder if it really makes sense, but at least PHP does not leave you without a solution.

4. PHP is only for Web development

PHP most common use is indeed for Web application development. Still you can run PHP outside a Web server using the PHP CLI (Command Line Interface) executable. It is a program that can be started from the command line shell for performing all sorts of operations, being Web site related or not.

Even CPU intensive applications are developed in PHP and run outside a Web server using the PHP CLI program, like for instance sending newsletters to many subscribers. The PHPClasses itself sends millions of newsletter messages every month using the PHP CLI program.

It is not as if there is great demand for developing these kinds of operating system specific applications, but if you need them, you can develop them in PHP too if you want.

5. PHP is controlled by only one company (Zend)

If you have already read about the PHP history you can realize that PHP was created by Rasmus Lerdorf in 1994. Over time Rasmus was joined by tens or even hundreds of other developers, including Andi Gutmans and Zeev Suraski, the founders of Zend, as well other core developers that work (or at least worked) for Zend.

I think it is only natural that Zend developers will always try to influence PHP development, so it takes directions that are convenient to their business. After all they have invested their whole business in PHP. If PHP development takes a route that makes Zend irrelevant, it would probably kills their business.

Still stating that PHP developement is controlled only by one company seems to be a great exaggeration. The fact is that PHP was developed and continues to be developed by many more people that are not associated with Zend.

There are even core developers that work for Microsoft, like Pierre Alain Joye, a long time PHP core developer that was hired by Microsoft in the recent years to make PHP run well with Windows and other Microsoft products. There are also developers from Oracle, not just to take care of Oracle database extensions, but also MySQL, which is now also an Oracle product since they acquired Sun.

The fact is that those PHP core developers that are connected to Zend, Microsoft, Oracle or other companies, are just a minority, despite their influence. The majority of core developers are not connected with any company.

If you are concerned that those companies can be evil and try to influence the development of PHP to go in the wrong direction, rest assured that all the other core developers that are not tied to any company are also concerned and watching out for any wrong moves. If you tried to watch the discussions in the PHP internals list for a while you probably have already realized that.

6. PHP documentation is bad or insufficient

This is probably the most amazing wrong claim I have seen, but I thought I should mention it because I have seen it more than once. Actually I even saw somebody stating that PHP documentation is so bad that it needs the user comments to fix it.

If there is only one good thing about PHP, that is certainly the documentation. The documentation is well structured, clear and, given the necessary time to the documentation team, very complete. The user comments that appear in documentation pages only make it even more rich and complete.

I have yet to see any other software project, Open Source or not, that has better documentation than PHP. The fact that it includes user comments qualify the PHP documentation project to be titled: Documentation 2.0 - used enhanced documentation.

The PHP documentation team does an amazing job. Not only they take care of the main documentation in English, but they also have teams dedicated to translate it to tens of other idioms. That is certainly part of the reason why PHP is so popular everywhere in the world. Kudos to everybody that helps in the PHP documentation.

Still the PHP documentation team cannot do miracles. The aspects that PHP covers are so extensive, that it is impossible to know every obscure detail that may make PHP work in a different way that it is expected in certain platforms. There can be bugs in PHP that may cause incorrect behavior, but that is not the fault of the PHP documentation team.

That is why the user comments are so important. They provide additional information that lets other PHP users learn about unexpected behavior that the documentation team could not anticipate.

Additionally, you may often find in documentation user comments sample code to perform certain tasks that PHP users wished that PHP functions could do. That makes PHP documentation with user comments even richer than it would be without the comments. Isn't that amazing?

7. PHP projects are not reusable because they are not Object Oriented

One of the reasons why PHP got so popular is the due to several killer applications that dominate the Web market. Several of them come to my mind like Wordpress, Drupal, Joomla, etc.. If you want to work as a PHP consultant, chances are that a good part of your clients will want you to integrate their sites with some of these applications.

Nowadays Wordpress is certainly the most popular of the PHP killer applications. Recently, Matt Mullenweg, the creator of the Wordpress project, announced in his State of the Word 2011 speech that Wordpress is present in 14.7% of the top one million Web sites according to the W3 Techs Web survey. That is a lot!

Matt also commented that many developers tweak their Wordpress installations with plug-ins to make it work as a CMS or eventually other types of applications.

Still Wordpress code is mostly written in non-Object Oriented code. It ships with same base classes to implement some common functionality, but the core functionality is written in procedural code.

This makes evident the fact that not being written with Object Oriented code is not necessary to make the project reusable, even for other purposes that are way beyond the original blogging platform purpose.

But wait, do not get me wrong. This is the PHPClasses site. One of the rules that is mandatory to have PHP components accepted for publication in the PHPClasses site, is that the code that implements the described functionality must be written in the form of classes of Object Oriented code, thus the name of the site: PHP Classes.

The reason for this requirement is that classes encapsulate functionality inside a container called a class. If component functions were global, there would be a greater chance of name clashing when combining multiple components of different sources.

For instance, if two components had a function named "print" , how would the applications tell which of the components they want to call the function print? Classes make it easier to encapsulate functions with the same names within different scopes.

But there is a workaround to avoid that problem without resorting to classes. You can just add a prefix to the functions of each component in order to avoid name clashing. For instance, the MySQL extension provides functions with the prefix mysql_.

This is a very old solution used in the core PHP functions since ever, specially because until version 3 there was no Object Oriented support in PHP. But this practice was kept throughout the years even until today.

Admittedly it is not an elegant solution. Component function name clashing (encapsulation) is just one of the benefits of Object Oriented Programming. But nobody can say that it does not work, or that it prevents PHP projects from being reusable.

PHP comes with many extensions that provide many features but comparing a language with a full stack framework is like comparing pines with apples.

I think it is fair to compare PHP with Java, C#, Ruby, Python, or "insert the language of the jour here". It is also fair to compare Ruby on Rails, Django, etc.. with a similar PHP framework. As a matter of fact there are so many similar frameworks in PHP, that I am not mentioning anyone in specific here to avoid being unfair to the fans of each of them.

Personally I think that what the developers of any language need is not exactly to use a framework. What developers need is to embrace a methodology of development that makes them productive.

Once you adopt a consist development methodology, everything becomes mechanic and you take less time to produce that same volume of work, as you just need to repeat the same development steps consistently.

You do not really need to use a specific framework to adopt a consistent development method. For instance, I do not use any framework. I just follow the same development methodology that I have been evolving over the years, so nowadays I am quite productive using that methodology.

I follow good development practices like separating concerns into different code components, but I do not need any MVC framework. Actually I feel that MVC is often an inadequate design pattern for use in the development of scalable Web applications.

I usually separate application concerns in components that are can be distributed easily among different machines by the means of service layers. But that may be a subject for a different post.

The main point here is that you do not need to use the framework X to be productive. What matters is that you follow a consistent development methodology that makes your work mechanic and fluent.

The fact is that certain frameworks impose a certain development methodology. Those frameworks are being called "opinionated" because they reflect the opinion of their creators about how development should be.

So, if you invested in studying a methodology that a certain framework imposes and that makes you productive when you implement your Web applications, fine, stick with it.

But please do not come and tell that the framework X, of which you are a big fan, is the best solution, or worse like saying that PHP developers cannot be equally or more productive than you just because they do not use that other language framework that you love so much. That is just your opinion based just in your own experience. Do not underestimate other developers' experience.

9. PHP is not good for high performance scalable Web sites or applications

The way I see it, performance and scalability are not a matter of language, but rather a matter of application architecture.

When it comes to performance, as mentioned above, PHP is a compiled language, so its is speed is nowadays very good for most Web application purposes.

Facebook is certainly the largest site that was developed in PHP. They do not seem to have scalability issues due to their adoption of PHP.

It is true that they developed their own PHP to C++ compiler to make PHP applications run at top speed. It is also true that for CPU intensive applications, the gains of compiling PHP into a lower level language can be significant.

However, the reality is that most Web applications are not CPU intensive. For instance, one of the activities that Web applications spend most time on is accessing databases.

When your application executes a SQL query, most of the time is spent waiting for the database server to execute the query and return the results. Waiting for a query to execute on a database server in PHP or in a lower level language like C++ is going to take practically the same amount of time.

So, now you may wonder, if PHP can be in practice equally as fast as C++ for database based Web applications, why did Facebook people went through such a great effort to develop a PHP to C++ compiler?

The answer lies in the fact that they also changed the architecture. They do not just compile PHP into C++. They take the scripts of whole PHP applications, compile them into single ball of C++ code and generate a single executable that works as a multi-threaded Web server. Notice the emphasis on the multi-threaded word.

Multi-threaded Web servers use a single process to handle many simultaneous HTTP requests. That saves them a lot of RAM because multiple threads share the same memory pool. This means that they end up needing less Web server machines to handle the same load. For a company like Facebook that has thousands of server machines, the gains are significant.

For most other smaller Web sites, the gains are probably not significant enough to go through the effort of compiling PHP into C++.

That does not mean you should not make an effort to educate yourself to learn and to adopt good architecture optimization techniques. Many of those techniques have been covered in this blog in the PHP performance articles category. Go and read them when you can.

Still, most of those techniques are not language specific. You should adopt them regardless whether you develop your applications in PHP or other languages.

10. PHP developers are cheaper because they are not qualified

The economy works all in terms of offer and demand. If there is a product that is wanted by many customers and there is not enough quantity of the product on the market for sale, the prices tend to go up. On the other hand, if the product is abundant on the market and the customers are not buying it much, the prices tend to go down.

The same goes for jobs. If there are more companies looking for qualified candidates than those that are available for hire, the offered salaries tend to go up. On the other hand, if there are more candidates than companies willing to hire them, the offered salaries may go down.

The PHP market is huge because the Web is huge. There are many companies willing to hire qualified PHP Web developers. But for simpler jobs, they do not want to pay much because they can find plenty of candidates with sufficient qualifications. Those jobs can be as simple as installing and customizing existing PHP applications.

But for companies that need to hire developers that not only know PHP, but also have other more sophisticated skills like application architecture planning and deployment, developing high scale Web sites, handle security matters properly, search engine optimization, etc., companies tend to pay much better salaries because developers with all those qualifications are scarce.

So, it is not so much a matter a problem of the PHP developers. It is more a matter of the qualifications that are demanded by the types of PHP jobs that require PHP skills.

Other Wrong Ideas About PHP

Well, the list of misconceptions about PHP does not end here. I just listed a few that I found more important. I could mention a few more but you got the point.

I am sure that some of the misconceptions are spread by PHP that for some reason hate PHP. I think hating is such a waste of time. PHP is just a programming language. Programming languages are just tools to do a job.

A good professional should know more than just one language to eventually take more advantage of the opportunities that may show up in their careers. So my advice is that whether you love or hate PHP, do not just stick to PHP or that other language that you prefer instead of PHP.

I tried to cover several types of wrong ideas about PHP that make people erroneously avoid it, and so they lose opportunities. I am sure there are other wrong ideas about PHP that are being spread by people that waste time fighting the popularity of PHP.

What other wrong ideas did you find are being spread that you feel it would important to clarify for the benefit of those that love or hate PHP? Please, feel free to tell about other wrong ideas or comment on those that were mentioned in this article.