i'm looking at a tutorial which let me learn and make a webservice in REST using PHP to communicate a JSON to my iOS application.
I don't find any "good" tutorial or a tutorial which make me learn and create something which look like a bit like i want.
could you please help me and put me in the good direction ^^
Thanks guys !
Client
For the client side I would suggest you use RestKit which is a very convenient framework for consuming REST-based webservers. It works for XML And JSON. I have used it before and can definitely recommend it. There are also various examples, which shows you how to use the framework.
Server
Depending on what you want you might do one of the following options:
Easy: If you want to focus more on the client you can simply put your .json files in a folder in your Public folder of your dropbox and consume those data files. You can then make changes to them with the Text Editor of your choice
If you want to have more control and have a Database etc. I suggest using CakePHP, which is like Rails for PHP. You have a bit of a learning curve there but the framework is quite powerful and there are lots of resources out there. Like Rails it follows the MVC Paradigm.
Update:
I just stumbled upon a nice step-by-step tutorial for the iPhone which loads json-based twitter-data and displays it in a UITableView
Related
What is a good approach to building a web interface for updating xml documents in a marklogic database.
I came across roxy, which is a ruby gem for configuring and deploying marklogic applications, but after playing around with for a while it seemed that it was more helpful for querying and displaying data rather than updating documents.
Roxy is also a framework that allows you to:
- use/extend MarkLogic's REST API
- use Roxy's REST API - with CRUD rewrite rules in place for you to map to your controllers
- The mVCframework itself is also neatly organized and not overly complicated. We use it quite a bit.
So, if you do CRUD via MarkLogic's REST api or Roxy or any other, none of these actually give you a frontend of their own.
Our usual formula is a 2-tier solution using Roxy within the MarkLogic app server that also serves the front-end code written in AngularJS. Then everything is managed under Roxy nicely.
If you are interested in samplle 3-tier apps with CRUD support, have a look at github and search for samplestack. It's a set of reference frameworks for MarkLogic. It's for MarkLogic 8, but it may give you some ideas..
The MarkLogic REST API is a good place to start. That gives you a lot of control over the documents, including the ability to update them, while working with the language of your choice.
With Marklogic 8 you can use the new Node.js client + e.g. Express (a small web framework). If you like mainstream development, this seems the best way now.
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
This may sound like a dumb question on the surface, but why does the Hot Towel SPA Template include Breeze at all?
I've been spending the last few days learning Hot Towel and its dependencies, and as far as I can tell, nothing in the template actually uses Breeze. Perhaps that is going to change with some future release?
Sure, Breeze is a good library. But it's bound to CRUD methodology and requires you design your ApiControllers a particular way. (Metadata, SaveChanges, etc.) see here
It also guides you to Entity Framework. While this is more of a soft-dependency, since Breeze also shows a sample without it, it still guides you down a similar pattern of implementation using a modified repository pattern.
If you are using a NoSQL datastore, or CQRS patterns instead of CRUD, then Breeze becomes very difficult to use. There are alternative libraries for data access that work well in this style, such as AmplifyJS.
But the rest of Hot Towel is excellent! I especially like Durandal. So the question begs, if the template isn't actually doing any data access - why include any data access component at all? It would be better to ship it without Breeze, and if the end-user wants to use Breeze, or Amplify, or whatever - then so be it. The rest of Hot Towel would continue to shine as a great SPA implementation.
Matt - Good question. Since I created it I guess I should answer :)
When I built the template I had a focus on providing enough to get folks going with the right tools, and just enough starter code to guide the way. I did not want anyone ripping out code. I'm not a fan of templates that start you down a path and make you remove tons of files and code and change direction. Those are samples.
Samples are good. In fact, samples can be excellent (like the other templates, which I feel are more like samples). Those serve another purpose: to show how you can do things.
Back to the Hot Towel template ...if I include code that uses Breeze, I would be tempted to add a datacontext.js and a model.js on the client. They would contain data access code and code to extend the models on the client. Then I would be tempted to add a controller, some server side models, an ORM and a database. Once there, I'd want to use the data in multiple screens, which leads me to more Knockout and caching with Breeze. Then I might be tempted to add editing, which would lead to change tracking. Soon I have a full blown app. Or more conservatively, I have a sample again. While these approaches would provide more guidance on how to put these together, they would not help you "get started" with a template where you can just start building and adding your own code. If I stop short of some of these features, it's still walking down a road that requires you to change how I did it.
As it stands today, HotTowel is pretty darn close to a template in the truest sense. You create a new project and you are off and adding your own code.
You could argue (and you may be) that Breeze shouldn't be in there since I don't use it in the template. Nor do I use moment.js, BTW. However, I argue that they are both excellent libraries that I would not want to build a CRUD based SPA without them. Breeze is flexible, as you suggest, so you don't have to walk a specific path.
The best way to understand the value of Breeze is to build an app that has its features but without Breeze. Then you can see how much code that takes and how involved it is. For one such example, see my intermediate level SPA course at Pluralsight where I do exactly this: http://jpapa.me/spaps
So you ask "why Breeze?" ... because I strongly recommend it for building a SPA.
Thanks for asking and good luck !
Thanks for asking the question.
John, as author of HT, has offered an answer. I, as a principal of the Breeze project, am inclined to agree with him :)
HotTowel generates a foundation for you to build upon. It is not the building itself.
It is a foundation intended for a specific kind of application, a CRUD application based on a specific set of cooperating JavaScript and ASP.NET technologies. Breeze is a contributor ... but not the only one. Knockout, with its MVVM design and 2-way data binding, is particularly well-suited to the data-entry tasks typical of CRUD apps.
Of course there are other kinds of SPAs. There's an important class of apps that mostly present information and accept little user input. Such apps don't benefit as much from data binding and the people who write them can get pretty hostile about data binding in general and KO in particular.
My point is that HT targets a particular class of application ... one that happens to be immensely successful at least when measured by sustained popularity. It delivers the goods for people who build those apps. It may not be the right starting place for other kinds of apps.
It is true that the easy road to Breeze runs through Web API, EF, and a relational database. Take those away, and you may writing more code on the server (and a little more on the client). That may be the perfect trade-off for you.
The authors of Breeze would like to make that path easier. I don't think BreezeJS makes it harder. I don't understand your statement "Breeze becomes very difficult to use." Have you tried it?
Your client can communicate with any HTTP resource in any manner you chose. It is pretty easy to use existing Web API controllers (albeit easier with Breeze Web API controllers). You can use amplify.js if you prefer (btw, you can tell Breeze to make AJAX calls with amplify). You don't even have to use the Breeze EntityManager to query and save data if you don't want to.
The rest of BreezeJS may still have value for you. There remains plenty of work to do after you've figured out how you'll retrieve and store data and whether you prefer Entity-ChangeSet style or Command/Query style.
You'll have to find answers to these questions:
How will you shape the raw JSON data into bindable objects?
How will you hold on to these objects and share them across multiple screens without making redundant round-trips to the server?
How will you navigate from one object to a related object as you do when binding an Address to a combobox of StatesAndProvinces?
How will you track changes?
How will you validate them?
How will you store some or all of the data in local storage when the app "tombstones"?
Breeze can help with these chores even if you don't want it to query and save for you.
And if you're answer remains "I'll do all of that myself, thank you" ... well, removing Breeze from your HotTowel project is as easy as:
Uninstall-Package breeze.webapi
I'd like to use WebAPI as my API technology to:
Allow approved companies to enter/retrieve data in my systtem
Create a standard interface for my company's iOS/Android/etc. applications
Does anyone know of best practices for, and mechanisms used to implement, versioning of interfaces. Specifically, I don't want to break backwards compatibility if I make updates to my API. I'd like to know what versioning schemes people use and if WebAPI has any built in mechanisms supporting versioning without the need to set up routes/paths every time a new version is released. Any thoughts would be appreciated.
Update
After performing some research I think I know what I want to do, I'm not sure how to do it. Ideally during content negotiation I would like to use a media type passed by the user to specify which version of the API should be used (rather than hard-coding the URL) and hit the corresponding controller.
If you don't want the version to be included in the Url, the way to go is probably to implement IHttpControllerSelector. This blog post should give you a good starting point: Implementing API versioning in ASP.NET Web API
I recommend you take a look at Peter Williams' series of blog posts on versioning REST services. They explain the what and why. For the how, check out Mike Wasson's tutorial on how to create a custom media formatter.
I am confused about the current framework for a client/server architecture system.
You know, when we are writing a small demo, on the server side, we listen on a port and establish a TCP/UDP connection with client, after that, we do some customize work.
Well, my question is, when we are using a framework like Ruby on Rails, where can I put my customize work?
It seems these frameworks are just for people managing a website.
I can't add a comment, so some words more here.
Thanks for your answers. Actually, I know how to do socket programming to handle all the requrest. But since what I want to build is a product not a demo. I think a wide-used framework is what I need.
ACE and twisted seem good to do these things. But what about RoR? I saw many websites that you can use their APIs and get messages from their servers. Can't RoR do these things? If so, how can I implement HTTP + JSON communication between client and server without having a website page?
I checked several tutorials on RoR, they only told me how to build a website to present HTML files, but what I need is a mechanic to communicate between Server and Client.
Thank you.
Ruby on Rails is indeed designed for implementing a website or other HTTP-related things.
There are other frameworks out there for doing more generic server implementations. For example: ACE and Twisted.
Not sure I understand exactly what you're asking but it seems like you're looking for the Ruby sockets framework?
http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm
Is a pretty straightforward description of how to do basic port listening/reacting.
I assume you are looking for an explanation of where cusom code goes when the server is mostly built from reusable pieces coming from a framework.
Forgetting about Rails for now, many older, simpler frameworks started life as a simple way to build objects to represent the incoming request and the outgoing response on the server side. From there, your custom code would be in making decisions about what to do with the request, and what to write to the response.
A more complex framework may include a templating engine, which makes it easier to put a complete response together by filling in the blanks (like a user name) in an HTML template, avoiding the need to manually craft the whole HTML response in the server code.
A lot of modern frameworks allow you to write applications like this, and many provide other pieces of functionality to make common coding patterns quicker and easier to write.