Trying to find a way to rapidly develop web services on the Mac Server platform that will be served via Apache and need to be able to write to flat files or SQL Lite on the Mac.
We have .net, ObjC, C++, Python, and Java skills. We have done lots of web service work before on Windows and will probably go with Azure when we build out the product.
Our development server is on Mac OSX 10.5.8 and we are on a tight time and cost budget to get a prototype done for a small beta group (< than 500 transactions per day) that we can later rework.
We are thinking SOAP, possibly REST. Not sure what is available for Mac?
Any help appreciated // :)
If you are developing a service, you must have some idea what clients you are trying to serve. If those clients expect to talk to a SOAP service, you'll need SOAP. If you are just serving JavaScript code-in-a-browser, REST is probably sufficient.
Apache CXF, being 100% Open Source Java, can be used to build REST or SOAP services on MacOS or anywhere else. There are, of course, other options.
What about Ruby on Rails? Easy to deploy, runs great on the Mac - and is trivial to setup RESTful web services for.
If you dont need all the magic of Rails, the other (albeit) Ruby option would be to use Sinatra - I would challenge anyone to find a RESTful webservices library easier to use than that - its so elegant and so easy. I am primarilly a .Net developer, but I picked up Ruby and Sinatra in a heartbeat.
In either case, I would stay away from SOAP - In my opinion it's just too inflexible these days. In a web 2.0 world of live internet APIs making the webservices RESTful is the easier, faster (and smaller) option. We used to use SOAP exclusively where I work, but the reality is that it just doesnt deliever in the same way that REST does. With the accessibility of JSON and XML serialization frameworks out for any languge even the object passing is trivial. SOAP is harder to scale, is harder to test, uses more bandwidth and is not as flexible. Not everything can talk SOAP (out of the box), but tell me something that cant do a HTTP request?
Related
We're about to start a new project and I've been looking at some of the new web technologies. We want to build a RESTful api which a client can access. To date we've been using python with django/flask to build the api and using jquery for the front end.
I've read quite a bit on javascript frameworks such as emberjs and angular, as well as nodejs solutions like express, meteor and derby. I really like the idea that a site should 'auto update' when the model changes.I'm aware that there are some libraries like gevent which can help facilitate socket level communication, but it seems to be more of a patch than an elegant solution.
Ideally, I don't want to give up a proven technology, ie writing server code in python (or php,ruby whatever) for building my whole app on nodejs. Having a RESTful API is important since we want our services to be open and accessible.
Would it be a bad idea to have 2 servers and 1 client? 1 traditional api server communicating with a javascript framework on the client. Then also run a nodejs server alongside the api server which can somehow talk to the api and if it finds updates, passes it along to the client.
We want to build a RESTful api which a client can access.
Ideally, I don't want to give up a proven technology, ie writing server code in python (or php,ruby whatever) for building my whole app on nodejs.
Then you should probably go with Rails and Ember.js. I'll quote eviltrout (co-founder of discourse) which is build on ember and rails:
One amazing side effect of a rich client side app is you end up with a battle tested API. Our app has consumed our own API since day one, so we know it works.
If we want to create a native client for Android or iOS, it would be a lot easier because we already speak JSON fluently. If people want to build services that use Discourse, they won’t have to result to screen scraping. It’s a huge win for us and the developers that use our platform. 1
However you should keep in mind that ember is as of to date still a very young framework (rc3 v1.0.0).
I don't know what sort of application you are building (in respect to why you would want to use node) How to decide when to use Node.js?
We'll be developing mobile applications (for both iOS and Android platforms) that will be using web services. I'll be the one implementing the web services part and I plan on using Apache CXF.
It would be the first time I'm using CXF but I'm highly considering it because of its integration with Spring.
What are the potential issues (if any) with using CXF for mobile apps? If there are, is there supposed to be a better alternative to CXF? If there are none, any best practices I should also be considering?
Thanks!
I've been through the mobile ringer... WAP, J2ME, Brew, embedded languages, etc. Mobile development is exciting and also a bit scary...
Spring Integration: There is a big difference between * and **... be careful when setting up filters. It's easy to get out of hand securing end-points.
Authentication: How will your mobile devices authenticate and what is their role in Authentication, Authorization, and Access? Session management on occasionally connected devices - can get interesting. If a session goes stale how are you going to handle challenge / response?
App Security: Does your solution require SSL? Managing self-signed certificates is painful and time consuming. Do yourself and your mobile devs a favor and get a CA certificate in place up-front. You will save time (money) and a great deal of headache.
Proxy Power: Ideally, the people writing the front-end should be using an IDE that supports some kind of tethering for realtime debugging. Being able to add a breakpoint and introspect what's going on in the code... is mint. However, I haven't seen an IDE yet that gives front-end mobile devs the same experience as back-end devs. My guess is that your mobile devs are going all goo-goo eyes over jQuery. Understandably so! WebStorm and Aptana are good in the JS arena - but they're still evolving.
This is a problem front-end mobile devs need to work out... right? Yes... and no. Without proper tools everyone in the dev-chain will have to cook-up their own ways of answering questions like:
What did the mobile app send?
Was the request formed correctly?
What was the response?
Again, save yourself some time and finger-pointing and just sit down together (front and back-end devs) and work out a tech-stack that provides everyone optimal access to all app communications. Configurable logging on the server is a good idea to have in place from inception. Are you familiar with Firebug or Charles Proxy? A proxy can greatly simplify the debugging equation - just sayin'
Exceptions: Oh... and beware HTTP response codes. Exceptions on the server-side should be gracefully handled to prevent mobile consumers from choking on responses. Yikes - that's all I can say is YIKES!
Service / Life Cycle: Have you calculated the duration of the service and / or life cycle of your application? Knowing this can greatly impact architectural decisions.
Web Services: My knee-jerk reaction - is this the best technology for your product? Why Web Services? Can you come up with three concrete reasons why WS is the best option? From my experience, the most compact protocol will usually lead to the best user experience.
Food for thought... ASP.NET and JSon make a good pair.
http://encosia.com/using-jquery-to-consume-aspnet-json-web-services/
SOAP-XML is cumbersome. :-(
http://openlandscape.net/2009/09/25/call-soap-xm-web-services-with-jquery-ajax/
Have you considered RESTful Web Services? If you're using CXF... there are three different ways to build RESTful Web Services.
JAX-RS (CXF has an implementation of JSR-311 baked-in)
JAX-WS (more complicated - meh)
HTTP Binding (deprecated... may be removed from CXF in the future - fair warning)
More at: http://cxf.apache.org/docs/restful-services.html
Examples: http://solutionsfit.com/blog/2010/04/21/enterprise-mashups-with-restful-web-services-and-jquery-part-1/
Alternatives: There are so many great projects out there... Axis2 and Shiro come to mind. Without knowing more about your solution - it's difficult to recommend anything.
Final Thoughts: As a back-end dev, I would recommend getting familiar with the entire app tech stack and kick-off development with a series of small but functional samples that light the way through the obstacles mentioned above. Hold-on to the samples! They may prove useful in zeroing in on regression.
Mobile devices are getting faster and faster every day... it's true, but any dev worth their salt will know that they need to code to a common denominator if they want a mobile product to be widely consumed, adopted, and embraced.
This is sort of a generalized question.
What is the best possible solution/strategy/technique/technology to create an HTTP API/web-service using PHP + MySQL, which can be called from any platform - web (html), Flash, Mobile etc. - that supports call to web services or API.
I am going to develop this API/web-service primarily for games (they will be called from games being played on any platform), so speed, scalability and security - all are highly significant factors.
How to choose from SOAP, REST, XML-RPC etc. ?
Any idea about ready-made solutions that can help fulfill my requirement ?
Thanks
In this case I'd recommend a REST API. SOAP is a more complicated standard, and it makes it more difficult for those to interface to your API (for example, some PHP servers don't have SOAP enabled). As far as using PHP and MySQL to create a REST API, you can use something like Zend Rest Server to make the process easy.
for one of my applications I'd like to provide a minimal web interface. This core application is written in C++ and uses Qt4 as a framework. Since I'm also using some libraries I wrote to calculate some things and do some complex data management, I'd like to use this existing code as a backend to the web interface.
Idea 1: Using an embedded web server
The first thing I tried (and which worked to some degree) was using an embedded web server (mongoose). As you can imagine, it is just a very thin library and you have to implement a lot of things yourself (like session management, cookies, etc.).
Idea 2: Using a normal web server and adding a fcgi/cgi/scgi backend to my application
The next thing that came to my head was using a mature but compact web server (for instance, lighttpd) and simple provide a fcgi/scgi/cgi backend to it. I could write the web application using a good framework, like Pylons, PHP, or RoR, (...) and simply have an URL prefix, like /a/... which allows me to directly talk to the backend.
I tried to implement the libfcgi into my application, but it looks messier than needed (for instance you'd have to implement your own TCP/IP sockets to pass on data between your app and the web server and tunnel it through the FCGI library, meh)
Idea 3: Creating a command line version of my application which does the most basic things and use a normal web server and framework to do the rest
This is the third idea that came to my head. It is basically about creating a web application using a traditional way (PHP, RoR, etc.) and using a command line version of my application to process data and return it when needed.
I've got some experience with creating web applications, but I never had to do something like this, so I'd like to hear some ideas or suggestions. I'd like to use JavaScript on the browsers (AJAX, that is) and pass some JSON constructs between web browser and server to make the user experience a bit smoother.
So what are your suggestions, ideas on this? I don't want to re-invent the wheel, honestly.
I would never expose a custom written application to the net as front-end, for that servers like apache or lighthttp are build. They give you some serious security out of the box.
As for interaction of your app with that webserver, it depends a bit on the load and what kind of experience you have with writing software in PHP, python or other languages supported by your web server (via interpreter of course).
A slight load, and a command line tool accessed from PHP might do perfectly well.
A more heavy load and you might wish to implement a simple (SOAP?) server with Qt and access that from a python (or php) script.
That way you don't need to do layout in you app, and you also don't need to implement security all that much.
I'm currently researching a similar situation (custom web app backend using Qt), and the least bad option is FastCGI. Found something you might be interested in. Not production ready without some serious testing, but this might be a good starting point for Qt - FastCGI interop: FastCGIQt
I've used the FastCGI Protocol Driver library for a similar project (also a Qt application), the download link is at the end of that page [Libfastcgi]. Integration with the application turned out actually comparatively easy. Lighttpd + mod_fastcgi was used as web server. Can't say anything about FastCGIQt, though.
You Wt works well to provide a web interface to Qt based applications. Both have a similar programming style, and there's an example that demonstrates the integration with Qt.
Here is example of embedded QML-server: https://github.com/ncp1402/ql-server
I am a novice in web services. I am totally new to testing web services.
A new project demands that I test the web services, and the customer is in favor of any open source tool.
What is the approach to testing web services?
Also Please suggest a tool(with minimal scripting) to test web services?
Check out SoapUI - one of the best web service test tools - plus it's free!!
They also have a "Pro" version which costs - you can do more stuff, like load testing etc., but the free version is quite good enough for most of your testing, I'd say!
Given a WSDL (online or stored as file), it'll create stubs for each method, which you can then use to create requests (as XML), fill in the blanks (the parameter values), and then you can send off your request to the web service and see what comes back as a response.
SoapUI also allows you to write scripted tests than can be run over and over again.
Excellent tool - can't praise it enough!
Marc
Additionally you could use Firefox Poster in order to test your web service by passing XML-packets manually.
Check it here:
FF Poster
SoapUI is a great tool to test SOAP webservices. It allows you to test a SOAP client or a SOAP server.
Another very useful tool is Fiddler. Fiddler isn't necessarily aimed at testing webservices (it's a HTTP debugger), but since SOAP webservices run over HTTP, you can use it to testing. Another very important advantage of using Fiddler is the fact that you can test REST webservices also.
You might want to consider robot framework. It is a generic, keyword-driven testing framework. There are libraries for testing REST and SOAP based web services. It can also be used to test web pages (via a selenium library), databases, and a whole lot more.
robotframework has a ton of built-in keywords, and there are additional libraries that do much more. You are also able to develop your own keywords in python, java, .NET languages, or any other language.