I am programming a Symfony2 App. The structure of my Symfony2 app like:
Login (username / password)
Get Survey for this Login / for this User
User input / click answers. After each click a Ajax request save the answer
User submit survey after answering every question
I have no experience with mobile apps like IOS, Android or Windows. The mobile will created by an other team. The question ist quite common, but which steps i must realize? Are there any literature that you can recommend me?
What was the right way to create an API?
How far Symfony2 supports to create an API for this use cases?
Unfortunately I have no experience on REST, but i suspect this is necessary, right?
I look forward to each answer.
Let me state the obvious first, if you start building a project with technologies you don't know enough about, it WILL be a nightmare. So by all means take your time to learn what you need.
REST is the reccomended standard to build an API since it's native http native and it's quite simple and flexible at the same time. There are tons of simple tutorials on REST, starting from Wikipedia, so I won't link them here.
But I'll tell you a secret, a web service can simply be any web page that reply to your requests with structured data. I.e. even a non-REST series of "webpages" the reply with JSON data can be defined a web service.
By now you see that you can easily do that with Symfony. If you already know how to do stuff and show pages with Symfony, only add JSONResponse to the mix , and also the _format routing parameter, and you should be on a good way.
You just create a path (i.e. an action) for whatever the mobile application needs to do. Of course later on you will learn the beauty of REST and refactor your API accordingly, but first thing you build a working system.
Reading this blog post is a good start. Now if your application will only serve API responses there is the very good Symfony REST Edition which already includes all bundles and tools needed to create an API centric application with Symfony2.
You also have the Lionframe framework but I didn't tested it yet.
Related
I have developed one spring based java web application. In my project it is requirement to use alfresco as a CMS. For this I want to integrate this application with alfresco. So I decided to use alfresco java API's.
http://dev.alfresco.com/resource/docs/java/
But I am not getting how to use those API's to complete backend work of my web application. Suppose I would like to submit one form having user name & password fields in it. After click on submit button how can I handle request in backend so it will use Alfresco java API to process request and store details in database.
I have to do many operations in my project like upload file, play with documents, Submit different forms. view those forms etc.
My first question is am I going in right direction by using alfresco java API's. if yes then how can use those API? is there any other way to do this?
Any help would be appreciate!!!
Thanks in Advance,
Kailas Salunke.
Well, based on my experience, Alfresco is an excellent ECM but not suitable for being a CMS.
Apart from that, it is difficult to give suggestions, starting from the very general overview you have given, but things like user name and password have little to do with an ECM and storing of data in a database.
You have two options available.
One involve using the Web Content Management Quick Start, it's a Spring Surf app you can (not easily in my opinion) customize for your needs.
The other solutions, if you have an existing web app, rather than develop your own API have a look at CMIS, I have put a simple wikipedia explanation, you can dig further from there.
Then, when you are ready, have a look at Alfresco CMIS first, and the most used Java API for doing CMIS call, which is Apache Chemistry
CMIS, in its intent, guarantee that Alfresco could be replaced with any other CMIS compliant ECM. You can easily integrate Apache Chemistry in your Spring app.
I am in the process of creating an app (cross-platform with Ionic framework) and during my research about app with this framework I found the one created for HabitRPG and it is using an API to retrieve data, it totally suits my app as well, but I don't know where to start to create an API nor what to use.
I allready did some quick test with Spring, NodeJS and Symfony (with FOS) but I'm looking for something really easy to use and to setup but still to have a lot of flexibility (like manage security, users, and data visibility).
Is there a specific technology easy enough to start with ?
If you want to create a Web API and host it, you can perhaps have the look at APISpark (http://restlet.com/products/apispark/). It's an online plateform that allows to design your APIs following REST principles and then host them. The data are also managed by the platform.
Hope it helps.
Thierry
I'm, going to write a web app, which should be CRUD accessible from both, the web and native mobile device apps. For the latter i'm definitely committed to a REST API. Is it possible to realize that with Meteor.com ? Would it be an option to use Meteor for just the web and a second REST interface to directly talk to the mongo? Since the meteor client listens for changes in the mongodb this should not cause conflicts, does it?
As of 2015, look at Gadi's answer for the Meteorpedia entry on REST APIs, and at krose's answer comparing REST API packages. Discussion for folding REST APIs into core is on Hackpad. This question is a duplicate of How to expose a RESTful service with Meteor, which has much better answers. -- Dan Dascalescu
Old answer (2012) below.
For adding RESTful methods on top of your data, look into the Collection API written for Meteor:
https://github.com/crazytoad/meteor-collectionapi
As for authentication for accessing the database, take a look at this project:
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth
Both are definitely infantile in development, but you can create a RESTful API and integrate it with a mobile native client pretty easily.
There are a lot of duplicates of this question. I did a full write-on on this in Meteorpedia which I believe covers all issues:
http://www.meteorpedia.com/read/REST_API
The post reviews all 6 options for creating REST interfaces, from highest level (e.g. smart packages that handle everything for you) to lowest level (e.g. writing your own connectHandler).
Additionally the post covers when using a REST interface is the right or wrong thing to do in Meteor, references Meteor REST testing tools, and explains common pitfalls like CORS security issues.
If you are planning to develop a production application, then Meteor is not an option right now. Its under constant change, and there are still many common features it has to support before its ready to use, which will be quite some time.
For your Question, Somebody has already asked and answered the question about support for file uploading in meteor(also contains HTTP handing related information).
How would one handle a file upload with Meteor?
I have a web app, that also has an iPhone and Android app using the same API. It hasn't yet been made publicly available, so I wanted to look to convert from SOAP to REST.
I was only able to find a few tutorials that go into thorough explanations of how to code a REST web service, and of those I only found the MSDN one useful. The problem is I got really confused when they started using URI data types inside the object.
My question is, if you are converting SOAP to REST, do you have to recreate all the objects to add the URI? Am I not able to just have a REST entry point, then call one of the classes that retrieve the data?
Once the REST service is made it will only be used by my mobile apps, but not the website (since that can directly access the classes), which makes me not want to change the objects to add a URI. Is that a correct assumption to make, or should the web services also be called by the website?
Sorry if these are newbie questions, but I am struggling to get my head around REST, and I haven't had much experience creating the architecture of potentially high user base apps.
If anyone is able to point me to an actual code set, that would be helpful.
Edit: I am using VS2010, coding in C# and .Net 4.
Thanks a lot,
Andy
Im doing a very similar thing right now :). Rest via wcf isnt too hard, you do have to sometimes add your endpoints in the web config and give it the [webget]/[webinvoce] attributes in the refrence.cs of the web refrence when consuming though c# which is annoying.
Here is a code set i used when getting started. There are a few more on code project too.
I am working on a experimental website (which is accessible through web browser) that will act as a front-end to a restful interface (a sub-system). The website will serve as an interface between a user and the restful interface, as it will make http requests to the restful interface for almost all database operations. Authentication will probably be done using openid and authorization for the database operations will be done via oAuth.
Just out of curiousity, is this a feasible solution or I should develop two systems that accesses the database in parallel (i.e. the website has its own data access logic, and the restful interface has another data access logic)? And what are the pros/cons if I insist on doing it this way (it is just an experiment project for me to learn things like how OpenID and oAuth work in real life anyway) besides there will be more database queries and http requests generated for each transaction?
Your concept sounds quite feasible. I'd say that you'll get some fairly good wins out of this approach. For starters you'll get a large degree of code reuse since you'll be able to put other front ends on top of the RESTful service. Additionally, you'll be able to unit test this architecture with relative ease. Finally, you'll be able to give 3rd party developers access to the same API that you use (subject possibly to some restrictions) which will be a huge win when it comes to attracting customers and developers to your platform.
On the down side, depending on how you structure your back end you could run into the standard problem of granularity. Too much granularity and you'll end up making lots of connections for very little amounts of data. Too little and you'll get more data than you need in some cases. As for security, you should be able to lock down the back end so that requests can only be made under certain conditions: requests contain an authorization token, api key, etc.
Sounds good, but I'd recommend that you do this only if you plan to open up the restful API for other UI's to use, or simply to learn something cool. Support HTML XML and JSON for the interface.
Otherwise, use a great MVC framework instead (asp.net MVC, rails, cakephp). You'll end up with the same basic result but you'll be "strongerly" typed to the database.
with a modern javascript library your approach is quite straightforward.
ExtJS now has always had Ajax support, but it is now able to do this via a REST interface.
So, your ExtJS user interface components populate receive a URL. They populate themselves via a GET to the URL, and store update via POST to the URL.
This has worked really well on a project I'm currently working on. By applying RESTful principles there's an almost clinical separation between the front & backends - meaning it would be trivial undertaking to replace other. Plus, the API barely needs documenting, since it's an implementation of an existing mature standard.
Good luck,
Ian
woow! A question from 2009! And it's funny to read the answers. Many people seem to disagree with the web services approach and JS front end - which has nowadays become kind of standard, known as Single Page Applications..
I think the general approach you outline is quite feasible -- the main pro is flexibility, the main con is that it won't protect clueless users against their own ((expletive deleted)) abuses. As most users are likely to be clueless, this isn't feasible for mass consumption... but, it's fine for really leet users!-)
So to clarify, you want to have your web UI call into your web service, which in turn calls into the database?
This is exactly the path I took for a recent project and I think it was a mistake because you end up creating a lot of extra work. Here's why:
When you are coding your web service, you will create a library to wrap database calls, which is typical. No problem there.
But then when you code your web UI, you will end up creating another library to wrap calls into the REST interface... because otherwise it will get cumbersome making all the raw HTTP calls.
So you essentially created 2 data access libraries, one to wrap DB and the other to wrap the Web service calls. This basically doubles the amount of work you do, because for every operation on a resource, you will end up implementing in both libraries. This gets tiring real fast.
The simpler alternative is to create a single library that wraps access to the database, as before, then use that library from BOTH the web UI and web service.
This is assuming that your web UI and web service reside on the same network and both have direct access to the backend database server (which was the case for me). In this setup having both go directly to the database is also a lot more efficient then having the UI go through the web service.