As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
( Not a duplicate of Should i use rest or soap. That question has only 1 answer which doesnt provide many arguments except overhead ).
Before marking this question as a duplicate, consider that I am looking for answers from people that made the choice before me and that explain their reasons based on their own experience. Answers that simply state "overhead" or "more complex" do not fit that profile.
Now for the question:
A while back I've started to setup a new api using Soap (PHP / Zend_Soap_Server, Zend_Soap_Autodiscover). Although I've figured out how to work with soap, the complexity makes me wonder if this is a good choice for future maintenance.
I've heard about REST, but do not have any experience with it.
So the question is: what are the pro/cons of REST vs SOAP and what is your suggestion when creating a fresh new api (rather complex api, several dozens of methods, using ssl, must have decent security etc), REST or SOAP.
If you think your answer hangs in the balance between REST and SOAP and a specific dependency or feature would tip the scale, be sure to ask whatever you need to know. I'll answer as soon as I can.
A short list of the api's features:
Authentication
Perform math functions for a frontend
Provide binary files to the frontend (invoices)
Basic CRUD of various sorts of information
The place of the api is basically as follows:
Internet -> website -> [internal network] -> API/Backend -> Database
Thank you for your time in advance..
This is of course a very controversial topic, but at the same time, most new services are REST for a number of reasons. I won't cover the differences between the two (as that is well documented) but more the reasons I think you'd build a new service, today (2012) using REST:
REST is much simpler, basically just building on top of HTTP
You can test (and debug) REST services using a web browser or something like curl or httpie. Yes this is technically possible with SOAP as well, but you have to somewhat understand the SOAP schema.
Similarly, you can build a REST client as long as you have a way to access HTTP. SOAP requires a SOAP-capable library
REST is more of a style and builds on top of HTTP, whereas SOAP is an entire protocol on top of HTTP (which is also a protocol)
SOAP ends up with crazy extension protocols like WS-Security, WS-Encryption (which, essentially, are incredibly complex designed-by-committee solutions to problems the rest of the internet solved for HTTP a couple decades ago)
If you look around at some of the major APIs on the internet (eg Google, Facebook, Twitter, etc) you'll find a lot of REST, and little to no SOAP. Those that do have SOAP interfaces are deprecating or dropping them completely, because there's very little reason to stick with it any more.
In fact, many of the big services are going a step further and only offering their REST services with JSON formatting, as opposed to XML or both, because like REST over SOAP, JSON has a lot of advantages in terms of size and simplicity over XML that it doesn't make much sense to continue supporting XML.
There are also almost no drawbacks to REST compared to SOAP.
About the only practical consideration I can think of is from a client perspective. With SOAP (because of WSDL, assuming you produce one) you can point a SOAP-capable IDE at the service (such as VisualStudio) and it will generate a native client proxy API based on the remote service. This is somewhat nice in terms of getting up and running quickly, but has its own set of drawbacks: it forces you to use the objects defined in the service (whereas with REST, you can use your own object definitions as long as the data maps in), and depending on how the remote service handles versioning (or not) and how you use it, you may end up having to update major chunks of your app because of something as simple as a naming change.
From the server perspective, I really can't see any technical benefits to choosing SOAP over REST whatsoever.
TL;DR: SOAP is not necessarily bad, it's just that REST is better.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Me and my team will soon start the development of a new web (vtv) service.
Most of the stuff will be processed and handled through a json api but we need a decent control panel for users who want to access their data in a gui environment.
We are debating if it's worth the time to develop the control panel with a framework such as knockout or backbone or if we should just stick with our classic stack.
As a devoted Javascript fan and developer I have used both knockout and backbone for some minor apps on my spare time and I can already see how hard it is to put all these peaces together in a real production.
Is it really worth to spend extra money to follow the trends and give the user a speedier gui?
My company seems to be interested in fast bucks solely so please tell me arguments to use!
Thanks =)
I can't comment on Knockout, but Backbone is absolutely brilliant. It's a small framework to learn, and once you get the hang of it, you'll find it does what every framework of its kind should do: implement the bits that you would have implemented anyway, and think about the issues related to that that you'll realise a little down the line.
It provides a sensible event and object model system that handles the business of keeping server-side objects and client-side objects in sync and has a sensible view model with event bindings linking the two.
So to address your question, it really depends on what you're doing. If you're writing the kind of asynchronous application that uses models and gets data from an API, chances are you'll want to use the same architecture as Backbone. If you're not, you've either designed something very different and it'll be no use (so you can say 'it just doesn't fit') or you've made a mistake in your design and you'll soon need to re-write!
Knockout or Backbone will not help you give the user a 'speedier gui'
However, it will make development easier. The frameworks impose a structure on your code - which means its easier to maintain, other people on your team can read the code and understand the flow more easily. This means you can respond to user feedback faster and give your users a positive experience
For speed of the UI itself, you should use speed optimization techniques starting with investigating the causes of slowness of the UI
In general, I'd suggest you go ahead with the framework of your choice. Only good can come out of it
Generally you should choose a framework / library because it gives you added value or shortens development time.
If you have the time/money and want to learn to implement new technologies while writing software, that's great, go for it!
If you need to get things done quickly, use the right tool for the job.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I need to valorate what technology use for a web project, the team is composed by 4 developers and the time of the project is 1 year.
I'm more familiarized with php but the client is asking me to do it with JAVA EE.
I always have the same perception with Java and its frameworks:
So much xml and class in order to do simple things. In codeigniter I've to use 3 files (model, view and controller) with hibernate + spring + JSF I need more than 10 files!!!
An abusive use of the server. The javascript code lose importance and it's not good nowadays. Of course we can add javascript code but It seems "java web guys" prefer do the stuff on the server instead of the client.
Not good-looking application. Richfaces seems like a web of several years ago.
When I see a java application like liferay, alfresco, they looks heavy and very slowly.
I think I can be a little confused because lots of people and big companies continues using JAVA for the web. Why? it's about integration?
On the other hand Java is faster than PHP, but JAVA's servers need lots of memory (more expensive). In a server with many request we can improve with a language like php with bigger time per process and less memory per process because the server never is collapsed because of memory. Sometimes a JAVA server could collapsed because of memory and the average of response time in a real production environment would be bigger than php.
I'm really pleased with Codeigniter, why so many people thinks Java is better?
Thanks in advance,
Alberto
well I'm not using CodeIgniter so my comparison is already incomplete.
Question one would be: why do they ask for Java? Often big companies only offer Java or .Net environments for productive systems so they might not have the people to productively run PHP applications. I know its not complicated but the maintenance people define what they are running.
Ofter people talk on languages and their features but when the first business use case has to be discussed no framework will save you that amount of time to make it count. Most programming language will somehow solve the issue.
Java is not only RichFaces or JSF. There is a lot to choose from. A LOT. Not an advantage.
Stuff often forgotten is the tool support. Java comes along with a JVM that can be analyzed in detail what it does with its memory, garbage collector, threads and so on. Profilers in Java allow you to identify almost any memory leak within a few hours.
Most of the JVM monitoring works in realtime (with about 5% overhead).
Talking about tool: refactoring support is far beyond what PHP IDEs come along with.
You are correct if the first look at Java compared to PHP looks like elephants and horses. (ok the logo of php is an elephant, perfect comparison...). Horses are more flexible to turn around corners but they might not carry that much around.
I think from a language perspective Java is still more advanced than PHP. Namespaces, Classes, Type-Safety. These are somewhat available in PHP but still quite new.
Frameworks like Spring allow you to leverage your application on an architectural level and are more than just libraries.
I'm not the biggest Java EE fan, so I'll not complain on that.
A simple approach for you could be Tomcat+Spring+SpringMVC and a template engine for the GUIs. There is also GWT (Vaadin) if you target higher speed client behaviour (still a lot more out there).
There are lightweight approaches in Java too. I agree the standards in Java do have a more fatty tendency.
In my experience Java has no major drawbacks compared to PHP. The language choice will only affect success of the project if people come with less knowledge than required and spend too much time in learning things. And trying to find the right book about Java could be a project by its own :)
(counting as an advantage)
But I have no doubts PHP would allow you to finish the project.
I would rather look into the goals and requirements before choosing the technology. This often implies or simplifies a decision.
I hope I did answer at least one question here :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm designing a new website and I need a login system (Preferably in PHP and mySQL). I've written ad-hoc login systems before and I'm aware of all the security involved, etc. But as Jeff Atwood said, Never design what you can steal. So I'm wondering if there are any good PHP login/sign-in libraries. Can you recommend any?
some specifics
I am trying to avoid php frameworks if at all possible (there is no reason to import one just for the login function)
Also, I am aware I could simply use a social login or open-id, unless you are aware of a REALLY good library for this I would also prefer to not have to have to use something (open-id) I've never dealt with before
Finally I need to be able to edit the user information in the mySQL database
UserCake
http://usercake.com/
Login Register Lost password recovery
Update password Update user email
Email templates (optional) SHA1
security + Salt / Hash Account
activation (optional) Resend
activation email (optional) User
groups (Basic, id - group_name)
Multilingual support
Or
You can try
http://phpuserclass.com/
Some points before the answer.
You may rethink your strategy on frameworks. Modern frameworks like Zend Framework and also Symfony2 are loosely coupled. This means: you dont need to download/use the whole framework.
Another reason to rethink it, is that these frameworks are often robust, widely tested and used. In terms of performance they are not always of huge impact, especially with apc and other optimization methods, so are you affraid you will use too much harddisk space?
Your question is about something specific but easily done. This is exactly the type of stuff that frameworks are good at. Codeigniter, Zend Framework, Symfony, Symfony2 (am I missing one?), all offer code that will allow you to do this in maximum a matter of hours.
Libraries I would consider
Zend_Auth (has only zend_exception as hard depencencies). It's lightweight and has many options for integration with openauth and such. (requires about 10 php files) http://framework.zend.com/manual/en/zend.auth.html
Apache ZetaComponents (before ezcomponents)
http://incubator.apache.org/zetacomponents/documentation/trunk/Authentication/tutorial.html
Pear LiveUser
http://pear.php.net/package/LiveUser/download/
If you were to consider codeigniter, check this out: http://codeigniter.com/wiki/Category:Libraries::Authentication/
This tutorial is a bit on the old side, but it is one of the best out there and is very well done. There's no framework, it's just plain old good OOP PHP.]1 The code is available for download on the Tut.
It's well written, includes Cookies, and has a robust back end for user admin.
If the libraries you find do not apply, many of the concepts I presume you'll look into involve either combining PHP and LDAP, and/or PHP and the Apache authentication modules.
Your authentication requirements should also respect the principles of defense in depth.
Also, you might need to discover if your project requires authentication for JSON, XML-RPC, or REST APIs that could be operated by non-browser clients.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Remember Aptana Jaxer? It plugs into Apache and allows using JavaScript on the server-side as an alternative to languages such as PHP. It comes with a consistens and slick API for filesystem access, database connectivity, socket communication and whatever else you need.
I wonder why hasn't this been more widely adopted, why aren't more people using this? Javascript is a modern and clean programming language as opposed to PHP and the Jaxer API is just so much more consistent and neat. No offense, but the PHP API is just such a big mess with all its inconsistencies and its inconsequent function naming convention.
Jaxer also makes client/server communication really convenient with its runat="server-proxy" where you can directly call server-side function from within your client-side script and Jaxer takes care of all the XML HTTP request stuff.
So I would just really like to here what people think about it or why there's hardly anyone using it. Not wanting to start a flamewar here, I'm just curious.
Thanks
Well, first of all, there is Node.JS out there, too. Far more people have heard of that, probably. And people do use node, especially when it comes to chats and similar things: Things there long-polling is appreciated.
My personal problem with node is, that it is so asynchronous. That's a very, very, very big pro on one hand, because is allows most awesome performance and makes some things so much easier, but on the other hand it is a big minus for those used to synchronous programming languages. I simply have problems with looking at code which has 15 callbacks nested in each other...
I remember taking a look at Jaxer, back when it came out. I don't remember any sample applications at the time though. I wanted to get a feel for what it was good at. Just because a language is "cleaner", may not be enough to get people switch. What is its "unique benefit"? For example, Node.js is good at real-time applications and they make that relatively clear in the sample code on their front page.
I think there was also been more uptake of Javascript, since Jaxer was initially released. There seem to be more back-end developers who now also know Javascript. I would say that's more true now than when Jaxer was released. In other words, maybe it was ahead of its time.
Personally I liked Jaxer, because you easily could use the same code client and server-side without duplication (such as form validation), however I didn't like, that you had hardly any control over the generated pages, which where propped full of JavaScript even for the most trivial page and made the pages highly depended on JavaScript, which made unobtrusive JavaScript virtually impossible.
So I guess for purely JavaScript-based web apps it's ok, however now there is for example Google Web Toolkit, which is much more powerful, which basicly also allows you to use one language client and server-side.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm building my own Ajax website, and I'm contemplating between REST and RPC.
If my server supported Servlets I'd just install persevere and end the problem, but my server doesn't support Servlets.
RPC is simpler to code (IMO) and can be written in PHP easily. All I need is a database query executer. I'm using the Dojo Toolkit and JSON.
Why should I choose REST over RPC or RPC over REST?
The best way to understand it is to read Roy T. Fielding's dissertation on it, or relevant articles on his blog where he discusses the differences between pure REST and simply RPC architectures.
Another thing to note is that the Wikipedia article on REST is in dismal condition and Fielding himself, the 'inventor' of REST, suggests that the article is inaccurate.
The biggest thing people miss with REST is discoverability - resources should include URIs for other related resources inside their hypertext, instead of relying on URI naming conventions, which are out-of-band and non-standardized.
A big problem with popular RPC implementations like SOAP or XML-RPC is that they use HTTP underneath their own proprietary architecture, rather than taking advantage of all the different properties of HTTP like PUT, GET, DELETE etc. So this doesn't fit the traditional web stack as well - a cache server in the middle doesn't work, for example, without knowing about the meaning of the contents of the RPC call.
This is an incomplete introduction to REST and RPC but I think I've highlighted some of the important points that are often missed. Be careful, since there is a LOT of wrong information out there on REST.
That said, REST is not for everything. It's an architecture, so it's rather flexible how you can implement it. But if it doesn't make sense to access things primarily as resources, then REST may not fit, or it may only fit for parts of your application, which is fine.
Uhm ... to put it simple, both are very abstract models ... so abstract, they naturally occur everywhere...
REST is the idea of having resources addressed with a global identifier (the URI in the case of HTTP) that are accessed in a CRUD way (using POST, GET, PUT and DELETE in the case of HTTP ... well, at least that's the idea)...
RPC is the idea where you call a procedure on a different machine, passing in some parameters, and taking a return value...
There is a nice short comparison on Wikipedia
Persevere creates a service, that allows both (in a very elegant way, admittedly) ... it is RESTful (although it does not only use HTTP-features to achieve this) and exposes an RPC interface...
In the end, you should look at what your application needs to do ... as most people, you'll probably wind up with an RPC API (be it based on XML or JSON or whatever), that includes a transport layer for a partially RESTful subsystem ... this is, because having RESTfulnes, means flexibility ... if the client can more or less freely traverse the data on the server (through a set of simple CRUD methods), it does not depend on a limited (problem-specific) set of methods exposed through the API, and you can shift logic clientwards...
There are three different styles of services:
RPC API - the client sends a procedure and parameters to service and the service is responsible for the executing of the command and returning a result.
Message API (Document API) - the client sends DOMs (elements), which normally are more complex structures than RPC API calls, because they tend to do not imply operations directly.
Resource API - is used for accessing resources (database tuples, files, images and etc.). In general it should also provide good Media Type Negotiation.
SOAP and REST are compilation of standards from W3C, and the main difference is that SOAP uses HTTP, SMTP and etc. as transport protocols and REST uses it as application protocol, AKA it should support (GET, PUT, PUSH, DELETE, and POST). SOAP also implies using XML and REST could use any data type (JSON, XML, HTTP, etc.). Furthermore, one of the main advantages of SOAP is the Service Descriptor (WSDL file), which gives the possibility of auto-generation of Service Connector (proxy) to the client.
There is not a silver bullet; the type and architecture of a web service are dependent on the actual client and technology requirements.
For a general idea on the subject, see one of the Martin Fowler signature books - Service Design Patterns