Can I use TIBCO General Interface with PHP? Or better, with CakePHP? If it's possible, how can I do that? Maybe some documentation in the web? (I search but I don't find anything). Thanks.
Yes, a PHP application can generate all of the data formats which GI uses, such as raw XML, JSON, or SOAP.
Have a look here: http://uk.php.net/soap to get started writing PHP-based web services
Related
I haven't found a suitable solution for this problem yet.
We haven't started the development, but we chose python for various reasons. So I don't wanna switch to PHP just because of an api-sdk.
Here are my thoughts for a possible solution:
Rewrite the api-sdk in Python. It's not extremely complex. I guess it will take 3-5 days. However we have to update the sdk by ourself. And the api, for what the sdk is made for, changes a lot.
Write a wrapper around the sdk. That enables us to call each single sdk-function by executing a php file in python like execfile(filename).
Or I use a wrapper to make the sdk-functions accessible via url.
The sdk returns result objects (like productResult).
The problem with solution 2 and 3 is that I can't to use these result objects in python. Solution 2 & 3 have to return a JSON. So I would lose some functionality of the api.
I happy to discuss your thoughts on this.
Porting the "sdk" to Python is probably your best bet - using python-requests and a custom json deserializer should make it easy. You may also want to have a look at RestORM...
HI all,
I am designing an client - server application system. The Server provide 2 features: upload and download images. The clients (maybe Iphone, Android, WP7, ...) use these features to provide to end-users.
At this time, I can design the server as web-pages (such as upload.php, download.php) as well as webservices. Both ways work fine for me.
My question is: which one I use webservices or web-pages technical for my designing? And why?
Thanks.
To be honest with you, using something like SOAP for this seems like a lot of unnecessary effort. You can very easily accomplish this using form encoded data and the right query string parameters without going through the trouble of building SOAP envelopes and writing all of the XML. Granted, the system I described is very close to a REST webservice, so I suppose it depends on what you mean by "webservice." Either way though, given relatively simple system you've outlined, I don't think something like SOAP will give you a very good return on your investment.
I have an existing website written in PHP. I would like to add a REST API. I like how easy creating a RESTful API was using Django. Are there any CONS for using Django for the sole purpose of creating an API on a PHP powered website? Thanks in advance.
There are a couple of cons:
your codebase will be larger
every change in the data model on one side must be done on the other side aswell
it will require more resources from your server
you have 2 systems to maintain
But for the rest, I can see why it would be easier to do this with Django than it would be to do with a plain PHP API. I have my doubts that there are no PHP libraries available to do something similar though.
I love Django, but I'm not sure that it would benefit you here. Maybe I don't completely understand how you plan to use it, but it seems like if you already have your data access and logic done in PHP then you would have to re-code that in Python in order to leverage Django.
If what you really want is clean urls and simple url mapping then you could probably use CodeIgniter or CakePHP. That way you don't need to rewrite your existing code in Python or having the same code in 2 different languages.
I have started to try out noSQL databases now and are currently testing out couchDB. Seems like a good solution, but I really get some headache when I follow available examples on how to create views (queries) to select documents from a database and sort them.
Everything I can find is regarding JavaScript and it would be great to take part of some examples for PHP since that is the language we will use.
So, how do I create views using PHP for couchDB?
As far as I know, the equivalent of the SQL language that would be used for a relationnal database is, for CouchDB, Javascript.
So, if you want to create some "query", or "view", you have to do it in that language : it's the one that's understood by CouchDb.
PHP and CouchDb are totally independant : the only thing is that :
PHP can send requests to CouchDb
and get results
But what happens on the CouchDb side is independant of your PHP script -- and there is no PHP on the CouchDb side.
The only way to filter results using PHP would be to :
Request more data from CouchDb than you need
And throw away, from PHP, what's not needed
But, obviously, that would not be an efficient solution...
Javascript is privileged as a CouchDB view server only because that's what's bundled with CouchDB. There are view server implementations for many other languages/runtimes, including PHP.
JavaScript (CouchDB native)
Common Lisp
PHP
Ruby (fork)
Python
couchdb-python
couchdb-pythonviews
Erlang
built-in view server
erlview
Clojure
Perl
Chicken Scheme
Coldfusion
Haskell
OCaml
I think you need to understand Javascript's stance in CouchDB. Javascript isn't a target language like PHP, Ruby, etc. Javascript is more equivalent to SQL here. The javascript is server-side and CouchDB itself actually executes it. This is what you use to do map/reduce and build views and such.
Try PHPillow man
Here's a very short introduction to it: http://www.catswhocode.com/blog/getting-started-with-couchdb-tutorial-a-beginners-guide
If you check out the SVN of PHPillow, there's more information in the 'docs' folder
as from Title.
Possible? Yes, everything is possible :)
But it is sensible? Hardly, it is too Python specific, I'm afraid, and therefore it would not be any fun to write a parser for Python data structures in PHP.
If you really need to do this, then I would recommend building a middle-layer in Python, which would then expose your ZODB over an interface that is usable in PHP. One possiblity would be using HTTP for the protocol and then JSON, XML or whatever else your heart desires for payload.
you could call the XML-RPC interface methods from PHP