Web applications and N-tier is interesting, mostly because the notion of N-tier has expanded with the widespread adoption of JSON and AJAX, or Flash and XMLRPC. This chart on Webopedia displays a staggered blue line that expresses this well. To summarize: your business, accessor, and presentation logic not only could exist on the server--but in some cases, right in the browser. The intention of N-tier, however, is separability. If you need to change out your UI or your database, or add other UIs, you shouldn't be affecting your business logic. And this is what would determine your API--anticipating the day your HTML and CSS are discarded for Flex, and MySQL is changed out for Oracle.
This is requirements determined, and in some web applications I've used, variations of N-tier are used simultaneously. Take for example LyrisHQ (an e-mail ASP). They have a customer web application. Recently, they have stared pushing their Flash based application. This clearly is shipping a lot of data right to the browser, and there is probably a bit of business logic duplicated in the Flash UI. They must maintain both applications, however, since either one is necessary for different (and overlapping) requirements.
Most common PHP applications are not considering shipping much unformatted data to the browser. But if you were, this would inform you very quickly how you would want to design your APIs. Very likely, you would want controllers that could talk XMLRPC, REST, or SOAP...in addition to a similar internal controller class that your PHP presentation templates used. This would strictly mean for a simple web login page, you would have a PHP template for the login form that talked to a LoginController class. An XML interface would likewise use the same LoginController class. Just as you would assume that you would be bonkers to write SQL into an Ajax request...you would be strictly avoiding writing queries into your presentation templates.
Business layers can be more or less strict, because often there is never a requirement to switch brands of database back-end. In a strict N-tier design, how your business objects would talk to your database would be as if you could switch from MySQL to MS SQL without rewriting the Business tier. Sometimes this is done by modeling objects for each table (Table Gateway), each row (active record), each join, or each transaction. This is where something like PDO or PHP-ADO are useful, but insufficient for complete isolation. ORM/Persistence layers in Java like Hibernate demonstrate better this kind of isolation, often by providing an Object Query Language (OQL).
Myself, I am presently undertaking a back-end transition from a MySQL based PHP application over to an MS-SQL one. The application has only ever used direct SQL queries. Imagine choosing how to take a series of queries in a class and either abstracting them, or subclassing, and hopefully not altering the business logic. At the very minimum, you will want to make all your SQL calls indirect. (S.O. post on PHP ORM.)
And finally, to your question about OOP: use it how you must to fulfill your requirements. My personal technique is to start with logic right in a PHP presentation template for a few minutes to get the ball rolling, pretty soon I'll refactor that into a class and a template. If I have common ideas, I break out routines into shared classes, striving to preserve the DNRY principle. (A S.O. post on that here. OOP is not a fundamental requirement for N-tier design. DNRY is very important for keeping your code maintainable, tho. Often deadlines and scope-shift destroy an API. Refactor it until you get what you need to keep going. I bet OOP will help get you there.