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().
Related
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 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.
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'm currently re-developing a fairly large-scale PHP web application. Part of this redevelopment involves moving the bulk of some fairly hefty business logic out of the core of the web app and moving it into a set of SOAP web services.
What's currently concerning me (just slightly) is perceived overhead this brings with it in terms of local HTTP traffic. I should explain that the SOAP web services currently, and for the foreseeable future, will reside on the same physical server, and if and when they move they will remain on the same network. What concerns me is the fact that for each call that was an internal php function call, it is now an http request invoking a similar function call.
Obviously this is something I can measure as we move further along the line, but I was wondering if anyone could offer any advice, or more importantly share any previous experience of taking an application down this route.
Are you doing hundreds or thousands of these calls a second? If not, then you probably don't have to worry.
But profile it. Set up a prototype of the system working across the network with a large number of SOAP calls, and see if it slows down to unacceptable levels.
If the server is running on the same physical box then you can't have any privilege seperation. And increasing capacity by adding tiers to the stack (instead of euivalent nodes) is a recipe for non-availability.
If you're hiding something behind SOAP, the the HTTP overhead is likely to be relatively small in comparison to what the 'something' is doing (e.g. reading from database). However when you add up the cost of constructing the SOAP request, decomposing the soap request the compositing the response, add the overhead for HTTP then one has to wonder why you don't provide a shortcut by calling the PHP code implemented within the server directly in the same thread of execution.
If you were to design an abstract soap interface which mapped directly to and from php types then this could be shortcutted without having any overhead in maintining different APIs.
Does it HAVE to be a SOAP web service? Is this the client telling you this, or is it your decision?
You seem concerned about HTTP calls, which is fine, but what about the overhead of unnecessarily serializing/de-serializing to/from XML to be transferred over the "wire" - that "wire" being the same machine. =)
It's doesnt really make sense to have a SOAP-based web service where it's only to be consumed by a client on the same machine.
However I agree with #Skilldrick's answer - its not going to be an issue as long as you are intelligent about your HTTP calls.
Cache whenever you can, batch your calls, etc.
SOAP is more verbose that REST. REST uses HTTP protocol to do the same with less network bandwith, if that's your concern.
See:
WhatIsREST
Wikipedia
As to really answer your question, remember the 80/20 rule. For that use a benchmarking/tracing tool to help you finding where your hotspots are. Fix those and forget about the rest.
Hello may be you can help me. I'm wondering about the fastest way to send and receive information between a WPF App (client) and a PHP (web hosting server).
Is TCP with sockets the way to go? or it'll have problems with the firewalls and IT related stuff?
Do you recommend me to go for a REST PHP version?
Webservices?
I would like to connect this two technologies in the fastest way without enviroument restriction (like the firewall or IT stuff).
Really, anything that uses HTTP on standard ports would probably work. At least, as well as it would be able to behind a firewall.
So that leaves your options open. Here's a few ideas:
Use JSON and normal HTTP requests.
Use XML and normal HTTP requests. (this may be a bit easier for the .NET side)
Use SOAP.
Use XML-RPC.
Pick one. The first two are easier to implement on the PHP side, and relatively easy to implement on the .NET side. SOAP is fairly easy to connect with .NET; I'm not sure about PHP SOAP libraries. XML-RPC is somewhat hard on the .NET side, and I'm not sure about the PHP side either.