I am very new to both iPhone APP development and PHP development though I have around 8 years of experience in .NET technologies. We have started developing an iPhone app which will talk to various third party API's like facebook, twitter, four square, google geo-code.
Now a lot of these interactions will have to happen from within APP itself for instance the initial authentication with facebook, posting messages to facebook etc. But we need some of the interactions to happen at the server for a variety of reasons and since I am a .NET developer the obvious means I could think of was web services.
We didn't want to use SOAP for a variety of reasons and we tried developing our own framework for web services using JSON but realized it would be too much of an effort to add features like security to the framework we are creating.
So we decided to go with an established framework like Zend where we could implement security and other features out of box. We also have to decide between using Zend Json-RPC and using Zend REST. The questions I have are multi-fold please understand I am very new to PHP development so some of my questions might be very basic.
I would like to know from any one who has developed iPhone app's interacting with a lot of third party API's how much interaction have you put in the server and are there any other efficient ways to communicate to a server other than using web services?
Between Zend REST and Zend RPC which is more secure and which will take less development effort I am guessing Zend REST will be more secure and Zend RPC will take less development effort.
Is it a good idea to use established framework like Zend for your development where we consider performance to be of utmost importance will using Zend add a over head in terms of performance?
How secure is Zend Json-RPC calls, how can I make the service calls more secure when using Zend Json-RPC.
I am a .NET developer transitioning into APP and PHP development so hoping to get some guidelines on the whole approach we are planning to take from some one experienced in these areas.
Lets see how to best answer this one.
Answer to 1
Haven't done an iPhone app. At work I build/maintain an Adobe AIR client side application that doing lots of services calls. My rule of thumbs is to do anything that makes sense on the client (take advantage of their resources) instead of nagging the server consistently. Usually our application loads all the info it needs from the server upfront and has enough data to do lots with. Every once in a while it needs to send that information back to the server to be stored in a secure location but most of the logic of how things work are in the client side app.
Since we are using Adobe technologies, we are using AMF as the transport protocol to send data back and forth between the client and server.
Answer to 2
Security will be up to you to handle. I talk more about this in step 4. For REST you are just passing a get/post/delete/etc with values that are not hidden. XMLRPC you are just passing an xml which anyone can see as well. Now, REST is a discussion on it's own. As there is no real standard it's hard to define what REST is when people are talking about it. If you want to use REST, I don't think Zend_Rest does a good job at really handling it. There are other frameworks that focus on REST that might work better for you. Also, if security is important use HTTPS instead of HTTP.
If you choose to do REST (the right way) I think it'll take you long to implement.
Answer to 3
It's all about how you architect it. I use Zend for the services I've described above at work. I've built it in a way where you can all the API using JSONRPC or AMF (and I can easily add XMLRPC or others if I want) and consume the same resource. I use AMF for our AIR application and I use JSONRPC for my PHP sites/tools. I like JSON better as I feel it's lighter weight than xml and for me it's easier to work with.
Next, I have cron jobs scheduled where every night I cache thousands of queries worth of data from the db into memory. Data that I know won't change in the next day and will be used quite often. Anything not cached by this process will be cached individually as it's requested by a client with a specific expiration time. What does this all mean, all my service calls are extremely fast and efficient. Many times I don't even have to hit the db so the time to process a request on the server side is a split second.
Also, if you use Zend, don't use the framework for an API, just use the server module as a standalone piece. Don't use the whole MVC stack, just create a standalone file for each protocol you want to use. I have a json.php which handles the JSONRPC requests and an amf.php file that handles AMF request. Both files inside are pretty lightweight, they just need to initiate the Zend_Json_Server or Zend_Amf_Server, assign the class path to where my classes are and handle the request.
Answer to 4
Which ever protocol you use, you'll have to build security into it like you would with anything. You can use the Zend authentication modules and acl as well. If you are passing sensitive data back and forth, whether it's json, xml, rest, you'll need to encrypt that data or some one will see it. AMF is a binary format making that a bit harder to do but that's besides the point. Which ever protocol you choose, you still need to build some authentication mechanism to make sure others don't use it without access.
If you are looking for more info on the different ways to build webservices using Zend I think the book Zend Framework Web Servicces is a good resource to start with. I hope this helps getting you started.
Related
Whats the best method for posting some data from a server side script, to a PHP web app on another server?
I have control over both ends, but I need to keep it as clean as possible.
I'm hoping people don't mistake this as a request for code, I'm not after anything like that, just a suitable method, even the name of a technology is good enough for me. (FYI the recipient web app will be built in Yii which supports REST if that matters).
Use cURL: http://curl.haxx.se
If you're calling from a PHP script, you can use PHP:cURL https://php.net/curl
Probably best to do it over SSL, if you want to keep the info safe.
Most of the answers here mention cURL, which is fine for smaller use-cases. However if you have more complex and/or growing needs, or plan to open up access to other servers in the future, you might want to consider creating and consuming a web service.
This article makes a somewhat compelling argument for RESTful web services over SOAP-based, but depending on who will be consuming the service, a SOAP-based web service can be both simple to consume (How to easily consume a web service from PHP) and set up (php web service example). Consuming a RESTful web service is easily done via cURL (Call a REST API in PHP).
The choice really comes down to scope and your consuming audience.
You can access your REST API with PHPs cURL Extension.
You will find examples here.
If you use a framework, some have alternatives to cURL, which are easier to handle (like Zend http client).
Or for very simple purposes (and if php-settings allow this), you could use file_get_contents().
I have several PHP libraries (scripts and classes and function files) that I want to make available as a service that is web accessible. I am trying to be as deliberate with the wording as possible since it seems that 'Web Service' is rather nuanced. From what I can tell there are 2 main flavors of Web Service, REST and WSDL/SOAP, with the later seeming to be more applicable to what I want to do, but it seems like a lot of overhead and possibly overkill. Could I simply make a PHP page that accepts a parameter of "function" to indicate what action to take, then echo out the response like normal? Requiring the construction of a SOAP message as part of an AJAX call seems horrible.
What is the difference between a requesting a PHP page and a Web Service response (aside from the SOAP protocol)?
Would you ever return a JSON string in SOAP?
Are the implementations separate, exclusive or in parallel?
Could you, or even want, to use Apache rewrites to accomplish nearly the same effect as REST or WSDL? Directing the request to a page appending a parameter for the requested action.
OR am I over thinking all this and should not worry about SOAP and just got with the standard PHP function parameter and return text or json?
I am also looking ahead a bit, since I work with a lot of legacy code bases, Ruby, Perl, Python, and Java, and would eventually want to make a Service from them as well. Or at least incorporate the libraries somehow.
I am going to recommend this book to you, which is an amazing reference for advanced PHP topics, and is very current. It has a chapter that focuses on networking with PHP, and a specific section on creating your own PHP-based web services. It also contains loads upon loads of other up-to-date kung fu for PHP developers.
http://www.amazon.com/PHP-Advanced-Object-Oriented-Programming-QuickPro/dp/0321832183/
I can tell you what worked for me.
I had to create a small web service in which an outside application needed to get a list of products. I echo'ed a JSON encoded array, while using .htpasswd to protect the data from prying eyes :). The data was accessible very easily with a small CURL script, and it took about 2-3 hours.
If you need the web service users to manage information, if you need an ACL, you will have to look into SOAP and/or REST more. For what I needed - it was more than enough.
I'm setting up a realtime app that will be using socket.io. There's currently some core functionally in php, that utilizes memcache and mysql backend.
Would it make sense in the socket.io server to do an ajax request (if that's even possible) to the php page that handles this? There's a lot of MySQL querying, I know it can be done in node.js, but I'd rather keep this part abstracted in php if possible.
So, my question is, is that a proper thing to do? Call a php page from within the socket.io server to then return to the client?
Thanks!
I don't see any problems with having your node.js app communicate with your PHP app by exposing a RESTful API or some PHP script that you can POST to or GET from your socket.io node.js server. There are plenty of npm modules (like request) that can make HTTP requests like that a breeze for you. After retrieving the data from PHP in your node app, you can use socket.io to emit() the data to the socket.io client on the frontend.
There is nothing wrong with that. You are simply using a RESTful API to access the MySQL data, thus isolating the database details.
If one day you are tired of PHP, you can easily switch to Ruby, Python or Whatever for that part without even touching the node.js. If your logic is already written in PHP (you are upgrading an old app), it make even more sense as you can reuse what has already been tested and debugged. A lot of folks are advocating for that kind of separation between systems. Just look at all the SOA (Service Oriented Architecture) buzz.
Where I work we are using this very architecture in a project (though in this case its an ASP.NET MVC Website calling a Java EE app) and it served us very well. With the event model of node.js, its even better since you won't block waiting for the PHP.
But of course, there are some drawback
Performance overhead
Architecture is more complicated
You now work with two language instead of only one (though javascript and PHP are so often used together that I don't think it's really is a problem in this case)
So you need to ask yourself if your problem really need that solution. But in a lot of case the answer may be yes. Just don't forget the virtue of Keeping It Simple and Stupid (the KISS principle)
I'd like to create an API for a project I'm working on, allowing developers to create desktop and mobile applications built around its functionality. One thing I've always wanted to learn how to do is create a stateless, push notification system, similar to Twitter's Streaming API.
Basically, I want to be able to notify users of any changes to the data in real time, or as close to it as possible. I know that this might be difficult on mobile devices, which is why mobile applications will probably be built to check for updates periodically, to save battery. However, desktop applications won't have that limitation. I'd like to avoid making the application ask the server if there is new information, and instead let the server tell the application that there is new data.
My programming language is PHP and my server is Apache. If I absolutely had to I could switch to Lighttpd or nginx, but that's an absolute last resort since it would require a lot of changes to all of my existing code.
I've read this article:
http://www.zeitoun.net/articles/comet_and_php/start
And tested it out, but unfortunately all that happens is my browser keeps attempting to load the page and never actually displays the time. I suspect this is because, for whatever reason, I've never been able to get output buffering to work on my server, unless I send 64kb (or more) of data. I heard that I had to disable gzip, which I did, and it still didn't work, so I don't know.
Have a look at some existing technologies to help you do this:
Tornado
Tornado is an open source version of the scalable, non-blocking web server and tools that power FriendFeed. The FriendFeed application is written using a web framework that looks a bit like web.py or Google's webapp, but with additional tools and optimizations to take advantage of the underlying non-blocking infrastructure.
Pusher
Pusher is a hosted API for quickly, easily and securely adding scalable realtime functionality via WebSockets to web and mobile apps.
Both are extremely fast and scalable, and I have setup both relatively easily.
Well you could do this in several ways, you could build in a poller at the client side, or you could use something like NodeJS. (http://nodejs.org/) or web sockets.
Yeah another good piece is
http://socket.io/
and
http://elephant.io/
some tuorials like this might also be useful.
http://www.phpbuilder.com/articles/application-architecture/optimization/creating-real-time-applications-with-php-and-websockets.html
I am developing an iPhone app and would like to create some sort of RESTful API so different users of the app can share information/data. To create a community of sorts.
Say my app is some sort of game, and I want the user to be able to post their highscore on a global leaderboard as well as maintain a list of friends and see their scores. My app is nothing like this but it shows the kind of collective information access I need to implement.
The way I could implement this is to set up a PHP and MySQL server and have a php script that interacts with the database and mediates the requests between the DB and each user on the iPhone, by taking a GET request and returning a JSON string.
Is this a good way to do it? Seems to me like using PHP is a slow way to implement this as opposed to say a compiled language. I could be very wrong though. I am trying to keep my hosting bills down because I plan to release the app for free. I do recognise that an implementation that performs better in terms of CPU cycles and RAM usage (e.g. something compiled written in say C#?) might require more expensive hosting solutions than say a LAMP server so might actually end up being more expensive in terms of $/request.
I also want my implementation to be scalable in the rare case that a lot of people start using the app. Does the usage volume shift the performance/$ ratio towards a different implementation? I.e. if I have 1k request/day it might be cheaper to use PHP+MySQL, but 1M requests/day might make using something else cheaper?
To summarise, how would you implement a (fairly simple) remote database that would be accessed remotely using HTTP(S) in order to minimise hosting bills? What kind of hosting solution and what kind of platform/language?
UPDATE: per Karl's suggestion I tried: Ruby (language) + Sinatra (framework) + Heroku (app hosting) + Amazon S3 (static file hosting). To anyone reading this who might have the same dilemma I had, this setup is amazing: effortlessly scalable (to "infinity"), affordable, easy to use. Thanks Karl!
Can't comment on DB specifics yet because I haven't implemented that yet although for my simple query requirements, CouchDB and MongoDB seem like good choices and they are integrated with Heroku.
Have you considered using Sinatra and hosting it on [Heroku]? This is exactly what Sinatra excels at (REST services). And hosting with Heroku may be free, depending on the amount of data you need to store. Just keep all your supporting files (images, javascript, css) on S3. You'll be in the cloud and flying in no time.
This may not fit with your PHP desires, but honestly, it doesn't get any easier than Sinatra.
It comes down to a tradeoff between cost vs experience.
if you have the expertise, I would definitely look into some form of cloud based infrastructure, something like Google App Engine. Which cloud platform you go with depends on what experience you have with different languages (AppEngine only works with Python/Java for e.g). Generally though, scalable cloud based platforms have more "gotchas" and need more know-how, because they are specifically tuned for high-end scalability (and thus require knowledge of enterprise level concepts in some cases).
If you want to be up and running as quickly and simply as possible I would personally go for a CakePHP install. Setup the model data to represent the basic entities you are managing, then use CakePHP's wonderful convention-loving magic to expose CRUD updates on these models with ease!
The technology you use to implement the REST services will have a far less significant impact on performance and hosting costs than the way you use HTTP. Learning to take advantage of HTTP is far more than simply learning how to use GET, PUT, POST and DELETE.
Use whatever server side technology you already know and spend some quality time reading RFC2616. You'll save yourself a ton of time and money.
In your case its database server that's accessed on each request. so even if you have compiled language (say C# or java) it wont matter much (unless you are doing some data transformation or processing).
So DB server have to scale well. here your choice of language and DB should be well configured with host OS.
In short PHP+MySQL is good if you are sending/receiving JSON strings and storing/retrieving in DB with minimum data processing.
next app gets popular and if your app don't require frequent updates to existing data then you can move such data to very high scalable databases like MongoDB (JSON friendly).