iphone & rest web service - what is the best practice?

I am developing an iphone app that uses a php web service for all functionalities. I am planning on creating model objects to communication between my UI and web service.

Is it better to create model classes on php to communicate between my iphone models and database? or is it ok to communicate directly from database to my model classes for iphone?

Which one of the following is the correct way of handling this communication?

• iphone-ui- => iphone-model-classes => web-service ==> database
• iphone-ui => iphone-model-classes => php-model开发者_如何学运维-classes => web-service ==> database

Why use PHP at all? Just use the relevant database library and connect to the database directly from the device!

There are lots of reasons why you might want something sitting between the phone and the database server:

• Authentication
• Data validation/integrity checking
• Logging/auditing
• Schema changes

Full-fledged model classes may seem a bit heavyweight (especially since PHP doesn't cache anything), but you need to decide on how you want to do stuff on the server side. In particular, you might want to use model classes and a persistence layer to avoid dealing directly with Sqlite/MySQL/Postgres/ODBC/blah.

There are also plenty of reasons why PHP isn't the best language for a web service...

EDIT: I was playing Devil's Advocate.

A "connection" to a database is often just a TCP connection (though pretty much all modern POSIXish DBs support connecting via Unix sockets, which is somewhat more secure). You generally need to implement the DB's protocol; the easiest way is to use the DB-provided C library (libpq5 for Postgresql 8.4, libmysqlclient16 for MySQL 5.1, etc). I'm pretty sure that iOS doesn't include them by default (but IIRC old versions of OSX used to come with Postgres).

However, this is very bad for security reasons:

• Most Linux distributions configure DB servers to only listen on Unix sockets (i.e. you can't connect to them via localhost). It's much easier to control access (only people who can access the file can connect), and allows for easy authentication as well (you can get the user ID of the process on the other end of the connection, which means you don't need passwords at all — this is the default config for Postgres).
• Most configurations that allow connecting over TCP do so because Java DB libraries typically don't support Unix sockets (because a "pure Java" implementation supposedly has advantages, despite the tiny amount of native code you'd need to use Unix sockets). Typically these only allow connections from localhost (not random places on the internet).
• If you're happy with the entire Internet having read-only access to the relevant tables, then it might be sensible. Otherwise, you'll want some sort of access control:
  • Allowing the wider Internet to write to your database is bad. You can't just embed a password into your app; the app will be cracked within a few days/weeks and, if an attacker is sufficiently curious, the password will be extracted.
  • Database access controls are per-DB or per-table, whereas you want to control access per-row (i.e. a user can see their own row in the "users" table, but not the row for other users).data for other users).
  • Databases servers typically don't do any form of rate-limiting on account logins, making it trivial to do an online bruteforce attack.

And again, you very rarely want the phone to talk directly to the database. It means your app stops working when you update the schema (a no-no; you're not supposed to force users to upgrade). It might be possible to put together some views/triggers/etc as a compatibility layer. Icky.

Secondly, relational databases are generally a bad fit for what real apps do. You want to scroll down a table view. Each cell is loaded from a database row. Each row is loaded over the network ... ouch. (After using CoreData once, I never want to look back. It makes my life much easier. While I wouldn't use it on the server side (our servers run Debian and our webservices are mostly written in Python), if I'm going to write the app in Objective-C, Core Data doesn't add any more vendor lock-in — I don't know anyone who takes GNUstep seriously.

Instead, it helps to consider the API you want to present to the web client. Most web services (Facebook, Twitter, probably others) seem to present a fairly "dumb", flat model of the world. Write the simplest thing that allows you implement the API you want. This might mean using model classes if it is sufficiently easy to do so (Google App Engine's modeling abstraction is nice; based off of Django's modeling abstraction, apparently).