CODEWITHSUNDEEP
phpapirestmobilemiddleware
Noel Llevares
Noel Llevares

Reputation: 16067

seeking advise for a mobile client-server application strategy

I'm seeking advice regarding the following plan that I have for a certain future project of mine.

I know that directly accessing the database (bypassing the web server) from the client is a bad idea especially over the internet. I think most shared webhosting plans prohibit this anyway. So here is my intended solution...

  1. Mobile client sends data to the webserver through an API call.
  2. The webserver processes the REST API call and queries the database. The webserver works as the middleware between mobile client and database server.
  3. The webserver receives the results from the DB queries and passes them to the mobile client.
  4. Mobile client displays/manipulates the data on the client-side.

My experience with APIs are limited to the consumption of Twitter, Instagram, and Google Shopping APIs. From my experience, it seems to be best to transport data between mobile and webserver in JSON format.

Now, here are my concerns...

  1. How can I ensure that only the logged-in users can use the API? Is OAuth the solution?
  2. For the REST API, is it better if it is RESTful?

The current environment of the website is on shared hosting with PHP and MySQL though I'm thinking of moving it to cloud-based services in the future. I'm planning to implement the middleware using either CodeIgniter or CakePHP or Apify.

I would appreciate if anyone can critique my plans above or present better alternatives than the ones I have in my head.

Thanks in advance.

Upvotes: 1

Views: 1132

Answers (1)

alganet
alganet

Reputation: 2547

REST is probably the best architecture for what you're looking for. The more RESTful you get, the better.

OAuth is an authorization protocol, which handles what websites has the authorization to use your credentials. Authorization is different from authentication, although one can use Authorization from another party to ensure authentication.

The choice on OAuth depends on the services you're building on. For example, if your application is based on Twitter, makes sense to use Twitter OAuth for authentication.

If your service will provide its own credentials, with every user having their own username/password stored by you, OAuth is probably not the best choice. On this scenario, you'll need to setup an OAuth client and an OAuth server, which is not necessary.

For own authentication, HTTP Digest Auth is a good choice: It is simple to implement, a lot of libraries already support it and it's secure enough for most cases.

Avoid sessions and cookies in PHP. REST is stateless and those features are full of client state on the server.

If one day you need to expand your service to more servers, synchronizing sessions between them is painful.

Take care of cache headers like Expires, ETag and Last-Modified. They improve the overall performance of the API and you can setup a reverse proxy (a middleware between your server and the client) that can cache things for you.

Public data on the API should not require authentication. When caching authenticated data, you can't share this cache between different users. Public data cache can be shared.

Both JSON and XML are easy to handle and manipulate. Sometimes JSON is better, sometimes XML is. See this answer for more info about differences on these formats.

Take a look at Respect\Rest, Varnish and Frapi. These are great tools for REST APIs.

Upvotes: 3

Related Questions