I have to prepare an architecture with following technologies:
Angular JS 1.5
MVC 5.0/Web API.
EF 6.0
Is it a good option to have a single web project which has angular JS and Web API.
We need to expose web api's to other third party vendors. So, we are thinking to create a separate web api project as a separate project. Need your inputs.
Thanks,
Dhannajay
You can have a lot of options to define the architecture, but to answer your questions, I think is better have separate projects in this case for the following reasons:
You can change the front-end without touch any in the api system (web api) and viceversa
You can scale both sites or only one, maybe, the front-end goes well, but you need more power in the web api, go ahead and scale only the api.
you can do this (like here)
API: your api front end
Core: business logic/EF
MVC: html/mvc/angularjs
DTO: classes/models
Related
I will start a new project with angularjs and symfony 2.
I just wanna know if my way, how I will realise it, is good.
The AngularJS frontend would be available over https://www.example.com and the backend of symfony would be under https://api.example.com.
So I hope that the routing of every framework would not colidate.
And I have also a available API for the mobile Devices.
Is this a best practice or is it better to use the api under https://www.example.com/api
IMO it is better to create 2 separate projects.
for the api (api.example.com)
for the front-end (example.com)
This way you avoid problems with:
routing (like you point - collisions)
sessions (api do not need sessions at all)
packages - e.g. your api could use symfony 3.1, but your front-end symfony 2.7
easier load balancing (IMO)
see:
Is it better to place a REST API on a subdomain or in a subfolder?
I have currently a visual studio that contains 3 projects :
MyApp.Models : Contains all my models with Code-First migrations
MyApp.Web : Contains my main website, only with MVC
MyApp.Pass : Contains a subdomain website, for customers.
We have new projects and we need to have those things :
A WebAPI that can be consumes by my main website, my pass website, a backoffice website, and a mobile application
a backoffice website that consumes WebApi, built with AngularJS
A mobile application that consumes WebApi, built with Xamarin
How can i layer my visual studio solution to only have one WebAPI that can be consume by all my differents websites/mobile app ?
Best regards,
I am currently building a side project - viewingbooker.com which is exactly the setup you are looking for.
What you need to bare in mind is that web api and mvc website have 2 different authentication techniques. Web Api 2 makes amazingly easy to authorise users from eg. xamarin mobile apps. Token is issued and is generally valid for 14 days of inactivity.
I have few projects within my solutions. Most importantly you need a separate project for your business logic. I also use DI to test my business logic as I go.
For website, I serve data as JSON from standard Controllers. For my mobile app, I have a separate web api project that serves the data separately. They both use business logic project so it keeps code redundancy to the minimum.
Remember that mobile app is not a website which you can quickly fix. If you end up using the same models and controllers for website and mobile apps, any change you make will brake your mobile apps and not all users have auto upgrade feature switched on on their mobile devices.
So I recommend you have a standard website with its own models and controllers, which is consumed by angular/knockout etc. Web API 2 project with its own models and controllers. Business logic project in the form of different services accessible by its interfaces so it's easier to test it. And don't get too paranoid with code redundancy that is different controllers, models for website/mobile. This approach will save you a lot of headache in the future - talking from experience.
I'm using HDIV for JSF and Spring MVC applications to mitigate OWASP top 10 security risks. Now I have to implement the same in AngularJS.
Is there any library avilable similar to HDIV for AngularJS?
For client-mvc scenarios such as AngularJS Spring-Hateoas approach fits well with HDIV. Actually, HDIV has a module for that integration: https://github.com/hdiv/hdiv/tree/hdiv-hateoas
It’s not totally finished yet but the integration of URL resources works (see ResourceRequestDataValueProcessor) but it’s not finished the support for forms. When we started this module this data format for forms was not finished or defined, and that’s why we did not continue this work.
We think it could be possible a very integrated solution with HDIV following Hypermedia and HATEOAS
approach for client-mvc apps or also for native mobile apps. In other words, within REST Hypermedia approach all URLs or forms, excepting the first URL, are created in the server side, in a similar way of traditional server side MVC web technologies.
Please take a look to this module (hdiv-hateoas) and we can support you if you have any doubts.
Roberto Velasco (HDIV team)
Integrating RESTFUL api in my application.
I've to use restful services in my new project. I'm using CakePHP 2.0.6
I do not want to create a restful services. I've to use restful services.
I want to know is there any ready made component is available in CakePhp to read restful services.
I want that component to serve me the output based on my services by doing the rest in the background.
Additionaly if the component is able to log it then it will be well and good.
A REST API is more a concept than a standard set of protocols, therefore there is no uniform way to interface with the APIs of different providers. Twitter has its own REST API, while Facebook provides another.
Most big webservices provide PHP classes to simplify interfacing with the API. For Twitter there's a third party library called TwitterOAuth and Facebook provides a PHP SDK. These can be loaded as Vendor files in CakePHP. See an earlier answer of mine regarding the loading of vendor files or this older post related to the 1.3 branch of Cake, but still relevant.
Several Cake developers have developed plugins for Cake to interact with popular webservices like the Facebook Plugin by webtechnick. Whereas loading vendor packages is the framework's equivalent of including them like you would in a plain PHP script, loading plugins is a bit different and might simplify things even more (or make them more abstract). The Cake manual entry on plugins has more information.
I've found a PHP Class from http://www.phpclasses.org Which is looks like taking care of most of the REST API part, And it worked for me for my purposes. It has got nice example file which will demonstrate how to use that class.
I've converted this class into Cakephp component. Here is the URL to download the class.
http://www.phpclasses.org/package/5480-PHP-Send-Web-services-requests-to-REST-servers.html
Check out CakePHP's HttpSocket utility. I have not used it yet but I think it's just an API for cURL which sounds like what you need. http://book.cakephp.org/2.0/en/core-utility-libraries/httpsocket.html
In this link: http://www.sencha.com/blog/spotlight-ext-js-customers/
Please scroll to the section :Why We Chose Ext JS
There is this line :
By using Ext JS, we lowered the cost
of developing a Web services API.
But I do not really get the explanation. How cost of developing a Web services API can be lowered by a client side framework?
I don't think the explanation conveys what the author intended. I think they were enthusiastic about ExtJs's AJAX APIs, which are easy to work with and can be called using a number of GUI components (which they mention).
The AJAX and component APIs do not create a server-side Web service API for you though, which their testimonial leads you to believe by saying:
This gives us the benefit of exposing
these same AJAX (JSON) calls, as a
Web services API, to our customers...
By using Ext JS, we lowered the cost
of developing a Web services API.
Well not quite, ExtJs doesn't create a Web Services API for you; it creates a method of interacting with your custom REST (or whatever) API. Although maybe they meant that since ExtJs defines how the client should interact with the server, via their numerous components, their server-side services were easier to create. For instance, ExtJs makes it easy to work with REST webservices, and it defines expectations in callbacks, etc. So in ExtJs providing the client solution, it was easier to devise a server solution (the webservices API) given half of a contract.