So I'm about to implement stripe payments to one of our projects and I've read the documentation of their API which stands as:
The Stripe API is organized around REST. Our API is designed to have
predictable, resource-oriented URLs and to use HTTP response codes to
indicate API errors. We use built-in HTTP features, like HTTP
authentication and HTTP verbs, which can be understood by
off-the-shelf HTTP clients, and we support cross-origin resource
sharing to allow you to interact securely with our API from a
client-side web application (though you should remember that you
should never expose your secret API key in any public website's
client-side code). JSON will be returned in all responses from the
API, including errors (though if you're using API bindings, we will
convert the response to the appropriate language-specific object).
They have a good pack of ready-to-use API libraries for popular languages so you import them to your favorite language and just start using their API, including PHP, which is what we are using for this project.
Now, their API is large and they have a lot of objects. We are not actually going to use the whole set of features so my initial thought was to just wrap around their HTTP RESTFul interface around simple cURL code so I don't have to load their whole set of classes for the sake of performance.
Now, before I actually implemented my own cURL client arount their HTTP API I took a couple of minutes to look at the sources of their PHP libraries and they seem to do exactly that: wrap around cURL functions, throw errors, expose objectified responses, etc.
Then the question is: Is it worth to just use their library even when I know I'll be loading a lot of clases I won't use, or should I write my own wrapper with cURL around their REST API?
Consider that this question came to my mind sice we are using other services (TangoCard, for instance) and most of them have deprecated "native" libraries favoring the use of whatever is your favorite HTTP client library and just use the REST API.
Thanks!
Loading classes is almost a non-issue in terms of performance, especially if you are using APC. I think the time saved by using what they give you completely justifies the slight performance loss due to loading their classes.
However, if their code is well written you shouldn't load any classes you don't actually use.
Also, if they maintain their library it will be easier to receive updates as time goes on. For instance, we used to roll our own Facebook APIs that used curl and had to stop due to their high number of updates and breaking changes over time.
I would strongly recommend using the official libraries.
Stripe's official code has certainly been developed carefully and tested deeply. Especially for important things like handling payments and dealing with customers' money, I believe you should want the most stable platform possible.
The difference in performance, even without caching systems such as APC, should be totally negligible, and unless your scale is comparable to Amazon's or other big online stores, I hardly doubt you should focus your resources in optimizing that part of the code.
Additionally, using the official library makes it easy to maintain and update the code in response to changes on Stripe's side.
Related
I am completing a website that I have developed in object oriented PHP.
It would be great if I could open my Application up to Windows Phone (because I love look and feel of the platform).
I have explored opening my application up by making use of the PHP SoapServer class. I've also looked at REST and retrieving data for my application as JSON, but it feels like a bitty solution.
Therefore, I would like to ask for advice on the following:
Is the SoapServer class the de facto technique for opening a PHP application up so that another platform (Windows Phone) can make use of it's classes/functions? Or are there other ways that I should consider "opening" my application up?
You can do several things, but the most used are the two you mentioned: SOAP and REST. There is no de facto standard. To be clear, because we are talking API here, there is no real difference between the fact you are using PHP (much less if it is object oriented or not), apart from how easy it is to handle your selected method server side.
I'm not a big fan of SOAP myself, especially in PHP. The support is not very good, but my experience in this is mostly in consuming SOAP, not serving it. Much of the advantages you get from reading your stuff from the .wsdl are gone if you cannot auto-import them // auto-create your classes, and the default SOAP implementation is a little too fond of just saying "segmentation error" in some cases.
That being said, your 2 choices are roughly devided by
SOAP: Stricter, more of an enterprise-setting, more difnitions and maybe therefore more control / forcing of standards. On the other hand, it can be complicated to use client-side
REST: More agile, very easy to understand for users of your API. On the other hand it does tend to create less consistent API, but that is not a given: you could be very precise in your definitions and not have this problem.
Personally I would choose a REST system in this environment. You can make your REST environment serve XML just as wel ofcourse, if you don't like JSON.
It's evident that the cURL functions are very widely used. But why is that? Is it really only because the extension is mostly enabled per default?
While I can certainly relate to not introducing 3rd party libraries over builtins (DOMDocument vs phpQuery), using curl appears somewhat odd to me. There are heaps of HTTP libraries like Zend_Http or PEAR Http_Request. And despite my disdain for needless object-oriented interfaces, the pull-parameter-procedural API of curl strikes me as less legible in comparison.
There is of course a reason for that. But I'm wondering if most PHP developers realize what else libcurl can actually be used for, and that it's not just a HTTP library?
Do you have examples or actual code which utilizes cURL for <any other things> it was made for?
Or if you just use it for HTTP, what are the reasons. Why are real PHP HTTP libraries seemingly avoided nowadays?
I think this would be related to why do people use the mysql functions instead of mysqli (more object oriented interface) or take a step further and use a data abstraction layer or PDOs.
HTTP_Request2 says that there is a cURL adapter available to wrap around PHP's cURL functions.
Personally a lot of the PEAR extensions I have tried out, I haven't been that impressed with (and I feel less confident with PEAR libraries that are sitting in alpha that haven't been updated in a long time). Whereas the HTTP_Request2 Library does look quite nice
I for one would have used cURL without thinking of looking at a possible PEAR library to use. So thanks for raising my awareness.
The libraries you mentioned aren't default, and from my experience in PHP, I prefer to use less of such libraries; they enable a broader attack surface, decrease reliability, open to future modification/deprecation more than PHP itself.
Then, there's the sockets functionality which, although I've used some times, I prefer to rely on a higher level approach whenever possible.
What have I used CURL for?
As some may know, I'm currently working on a PHP framework. The communication core extension (appropriately called "connect") makes use of CURL as it's base.
I've used it widely, from extracting favicons form websites (together with parser utilities and stuff) to standard API calls over HTTP as well as the FTP layer when PHP's FTP is disabled (through stream wrappers) - and we all know native PHP FTP ain't that reliable.
Functional reasons as mentioned in the comments:
It's very old, [widely used and] well tested code, works reliably
is usually enabled by default
allows very fine grained control over the details of the request.
This might need expanding. By nature of the common-denominator protocol API cURL might provide features that plain HTTP libraries in PHP can't...
Historic reasons:
curl used to be the only thing that could handle cookies, POST, file uploads...
A lot of curl use probably comes from tutorials that pre-date PHP 5.
My question is needed for some basic understanding of webservices and more specificly
in conjunction with php
I would like to know, if it is necessary to have a wsdl file for the creation of a webservice or is that just something that is usefull to third party's that want to access the webservice?
Also, it's generated automaticly in .net environments, but for php it's a bit more difficult.
What are my options?
The thing I am after is to create a jm2ee application on my mobile that sends data to the webservice from time to time.
I read somewhere that you have to supply the arguments when there is no wsdl file.
What is meant by that? and/or what are the implications of that?
Thanks in advance, Richard
I would like to know, if it is
neccasary to have a wsdl file for the
creation off a webservice
No, it is not necessary (at least, not in PHP) : it helps others know how to access your webservice (which methods, objects, ... should be used), but a WS can be called even if it doesn't export a WSDL
For PHP, yes, it is a bit difficult to get a WSDL (many classes don't generated them :-( ) ; still, you can generatd it with another tool (there are tools in Eclipse to write WSDL files, for example).
There was PEAR::Soap that was able to generate WSDL from PHP code (but you had to write down many lines of code to get it right) -- considering there is a class included in PHP 5 to work with SOAP, I wouldn't recommend using this one, anyway.
For more informations, you can have a look at :
SoapServer ; especially, if you look at the documentation of SoapServer::__construct, you will notice it can work both in WSDL and non-WSDL mode
Zend_Soap
If you are creating both the client and the web service, then there is no particular need to futz with SOAP, WSDL, or any of that jazz.
Just use the basics of the web: the client can use GET to fetch information, and POST to send it. You can format the data any way you like, but JSON and XML are common, well-defined approaches.
If you'd like inspiration for your API design, check out some popular examples:
Twitter API
Flickr API
all the Google APIs
all the Yahoo APIs
That's enough to get you started, but if you're curious about the design philosophy, you can read up on Representational State Transfer or REST.
WSDL file documents in a machine readable (XML) format what the methods (and args for methods) offered by a web service. You do not need a WSDL file if you know what the methods and args are - though WSDL is very good to have as a means of making the web service public interface more 'contractified', if you will.
To the best of my knowledge the PHP library does not have functions to automagically generate a WSDL file for you.
Web service support is built into php5, your best starting place is the documentation.
Some sources will use the term "webservice" as synonymous with SOAP. That is a misnomer. SOAP is a particular protocol - It is one way to create a web service. There are other technologies available. In general SOAP is the preferred standard with in Java and .net, but it is a bad fit outside of this sphere. If you have the option, I would strongly suggest that you consider either xml-rpc (Which is simpler and has better direct support on php) or a http-based service (Also called REST based).
Being as stubborn as it gets, I'm building my own PHP-based CMS and framework (named RAmen/FSM just for the kicks) that has been deployed multiple times for my customers. Now, I'm going to develop a support ticket application for it that I will deploy on a 'central' server for convenience of maintenance.
Now, I've looked into SOAP services and was happy until I got to WSDL generation in PHP and in itself. So, what would you suggest for me to 'securely' (as in, no https) manage this with SOAP-like simplicity on the client side ($support->newTicket), without the WSDL headaches on the server side? Or should I –gasp– stop being so stubborn and just go with a PHP library (in which case, please do recommend!)
Thank you, fellow pastafarians/spagnostic coders!
PHP has a native SOAP extension, that automates client as well as server. It is a little buggy in some places, but still better than nusoap (IMHO).
That said, I would never chose SOAP if I had any bearing on the decision. Use xml-rpc or a rest-based approach.
I have a similar question, whether to use REST or SOAP. I am using REST but that is beacuse i want a simple API like function not so much the rigid functionality associated with REST.
That being said here is a nice little library to get you started on SOAP
http://sourceforge.net/projects/nusoap/
By the sounds of it SOAP is actually what you want. you will fin it a bit easier to implement as you get the domain models from the WSDL.
What is the best method for communication between Flex and PHP?
In the past, we used AMFPHP with AS2, and it worked great for the most part (advantage of AMFPHP is that it also has a JSON mode that can let you seamlessly use the same remote PHP with either Javascript or Actionscript frontends).
However, it seems like AMFPHP isn't realy maintained anymore. So what do people recommend to replace it? So far, what I've found is:
Zend_AMF (looks too complex for us, we're not using the Zend framework otherwise)
AMFPHP (there were some updated made to support Flex, and it seems fairly stable, but not sure on long-term support)
XML (AS3 has nice XML handling routines, but it's more of a pain on the PHP side)
WebORB (I have no experience with this)
Roll-our-own using JSON or some other data-to-text serialization system (php's serialize(), XML, etc etc)
Mostly I'm leaning towards AMFPHP, even because of the downsides, since that's what I'm used to. Any reason I should consider switching to something else?
If you want to have fast and efficient communication, I highly recommend sticking with an AMF protocol instead of a REST or JSON custom format.
ZendAMF is actually not very confusing. Watch the introduction tutorial on GotoAndLearn, it's quite simple.
And just so you know, some of the developers from AMFPHP moved to work on ZendAMF. So in a sense, ZendAMF is the continuation of AMFPHP.
ZendAMF
Good short read - http://theflashblog.com/?p=441
For me this is no brainer. The Zend framework is one of the best php frameworks out there, and now you can talk to Flash clients. Top it off with Adobe support, that's a done deal in my book.
Alternatives :
WebORB for php
http://www.themidnightcoders.com/products/weborb-for-php
AMFPHP
http://www.amfphp.com
If you read the url above, you'll probably know why this is no longer on my radar.
I can't tell you what's best (because that's probably somewhat subjective anyway), but what I can do is tell you about a recent project of mine.
Since this was a very rich web app, and data requests to the server would be frequent, I wanted to make sure the size of the requests were as small as possible. This mean choosing JSON as the format.
Next, becuase of the nature of the application and the fact that my flash/flex developers were 1000 miles away, I needed an API that was simple and stateless. This ultimately led us to HTTP + REST.
So, the communication layer of my app is a simple Zend Framework powered set of REST resources with URIs like
user/10
review/15
location/8/reviews
They all return JSON. There's a common JSON format for all errors, as well (exceptions are trapped and converted into JSON objects) so that the flash client can easily handle failure.
If you're not using a framework like Zend, regular ol AMFPHP is still great, if for no other reason than that it's simple. I think if you feel comfortable with it, why not go for it? The thing about the role of these AMF interfaces is that they really don't need to do too much, and what AMFPHP does have in class mapping, recordset parsing into ArrayCollection, great performance.... it even does well with XML, since it gets compressed. The service browser combined with Charles has covered me as well.
I haven't been able to make much sense of how the ZendAMF effort relates to the original AMFPHP. While I can dig, I'm just saying that in following the AMFPHP mailing list on Nabble, reading Wade Arnold's blog... it's just not entirely clear.
You should consider using Zend AMF. The Zend Framework is designed to be a pick and chose framework so it is completely OK to pick a single component (in this case Zend AMF) for your application.
Zend AMF is extremely easy to use. All you have to do is specify the functions/classes you want to expose and specify class mapping to your action-script classes. Everything else is pretty much transparent.
This link is a screencast showing how to use WebORB for PHP WDMF (WebORB Data Management for Flex).
http://www.themidnightcoders.com/products/weborb-for-php/developer-den/screencasts/weborb-data-management-for-flex-and-php.html
In all projects involving Flash and PHP backend, I worked with either AMFPHP or XML requests.
AMFPHP really simplifies understanting the application for future maintenance, although it ties the whole thing to that specific technology and involves some additional overhead on the server side - to create all needed classes.
As per XML, well, what you gain here are standard REST webservices and it doesn't depend on Flash (you could pull data from a desktop app as well, for example, whereas using JSON or any other technology dependent on browsers don't allow for that).
If you want 100% future "support", then I'd recommend what doesn't need any support at all: XML.
XML on PHP can be a lot simpler with SimpleXML.
I'd just use JSON as your returns for simple calls against your PHP api.
I would definitely go for WebORB. I used it with .NET in a previous job I had and it was a joy to code with. Its ease of use and its well thought management console make it very fast to learn, and its documentation is very complete; I know it's tempting to stay with AMF just because it's what you already know, but I believe it's worth to give WebORB a try.
Take a look at this screencast for Actionscript generation with PHP, it's quite fancy.
Cheers.
PHP has a pretty good serialize() function, so for a recent project I did (high scores for a game), I used Sephiroth's Serializer. It makes the serialization on Flash's side nearly as easy as it is in PHP. Serializer also deals with datatypes (unlike json/xml) like AMF.
Downside--it's not as compact as AMF, but that's nothing gzip compression can't handle.
AMF has a pretty situational advantage. If you're looking to transfer large and complex Object, by all means go with AMF. But little does people know about the overhead that AMF carries when you're transferring small objects. If you're only transferring an object with 3 properties, using AMF can triple your payload size.
On a side note, I'm a big advocate of RESTful architecture. Since JSON and AMF are both just representations, you can build a REST service that accepts both, and negotiate the actual representation with your client at runtime.
"If you want to have fast and efficient communication, I highly recommend sticking with an AMF protocol"
And if you want a fast, efficient, and generalized communication, go with json. Then your web service will be available to flash, ajax, or regular http requests.