Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For people who follow the fairly new ASP.NET Web API, they know that it is a good framework for building well-designed and outwardly-facing HTTP services that can span across many different clients using standard XML or JSON content types.
I have been recently designing a large API to be used with both a web and mobile clients. I noticed that within the ASP.NET Web API template provided through Microsoft's NuGet packages for Web API, they take a very minimal approach into Views with a slightly pretty homepage.
This took me back in a way. Mainly because I would assume that the Web API is designed for exactly that, a Web API, and nothing else.
In other's opinions, is it standard to develop the web client (that interfaces with your API)
Inside the Web API project?
Or
Outside the Web API Project to separate the web client just as you would your mobile or desktop clients?
The second choice seems logical to me in ways of maintainability and code-cleanliness, but there may be other perspectives that could be beneficial when designing in ASP.NET Web API. What do you think?
Great to see you using Web API!
About your first issue, you're right that it conceptually makes sense to separate Web APIs from views. I'd recommend either using the "Empty" project type in the MVC new project dialog and then adding API controllers. Or adding the NuGet packages yourself to an empty web project. The packages shouldn't be adding any views to your project.
Concerning clients, I'd strongly recommend separating out a client library to a separate project for maintainability. It's fine to have common data types that you share between the client and the Web API though. In that case, it's a common pattern to move your models to a separate dll, and have both the client and the Web API reference the types in that library.
A couple reasons you'd want the client and the Web API to be separate (and there are many more):
If you distribute the library, you want to distribute the client code and not the Web API code
You want to create a clean contract between the client and the server and avoid having the client depend on the server implementation or vice versa.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
In my microservice architecture project ,it would have oauth service to authenticate the user and the gateway work as the front end api.
My question is where to write the register logic ?
In the oauth service or in the gateway?
Finally solution:
I do that in the user service and call from the gateway. Everything seems to work fine！
I believe best way is to place all authorization logic into library that is shared across microservices via private artifact repository. This library can configuration beans that can be component scanned when this JAR library is on classpath. component scan might be automatic, if you structure your packages wisely. Or you may want to make that scanning or including this shared logic explicit.
This way you might remove OAuth authorization logic duplication, which would otherwise be present.
Of course I am assuming that your microservices are Spring/Java based. If your microservices would vary programming languages, your authorization logic will be duplicated.
BTW, via shared library, you can cover also other cross cutting concerns of your Java/Spring microservices (monitoring, error hangling...). I've seen this working very well for teams working on 20+ microservices.
EDIT: Original response container workd "authentication", but I meant "authorization". Sorry for that confusion. "Authentication" should be in OAuth performed by separate dedicated service. This is not cross cutting concern, because there will be only one service accepting crendentials and returning back Oauth token. The best solution is to use third party OAuth provider, because you don't need to deal with credentials -> less security concerns for you. "Authorization" is cross cutting concern.
User registration is a separate bounded context so a separate microservice is the best approach. There is a blog post about this here.
Authentication is a cross cutting concern that could be handled by the API Gateway. This would free the upstream microservices of this responsibility - their main job is not verifying that a user is who he claims to be.
Authorization should be the responsibility of a dedicated microservice. It could be called by the API Gateway or by individual microservices.
P.S. My answer assumes that the microservices are not directly accessible from the outside, they can be reached only by the API Gateway.
So far I've been developing applications where I included services for both web and mobile applications in the single spring boot application where I've used different packages for different clients. But here The problems I faced are like, Since both clients are pointing to the same app in same server, Maintenance became difficult for me for e.g. When I update any service in Mobile part, whole code has deployed and things like this.
I do know it's more generic question.
But here the point in my question is, Is it really a good practice to provide APIs for both web and mobile client from the single application in the Server? Suggest me some good references
TL;DR is, as usual, "it depends" - on size, complexity, team structure and other factors.
Keep going with everything in a single project until a compelling reason to do otherwise emerges.
i was asked in an interview the following question about webapi
Why we need webapi?
I told "the services that are created in webapi can be used across wide range of devices like laptop, desktop, tablet and mobiles."
Then the interviewer asked why it cannot be done using web services and wcf?
I don't know the answer.
Can anyone let me know the answer.
Copying the title of your question into a search engine yielded the following link.
WCF and ASP.NET Web API
WCF is Microsoft’s unified programming model for building
service-oriented applications. It enables developers to build secure,
reliable, transacted solutions that integrate across platforms and
interoperate with existing investments. (ASP.NET Web API) is a framework
that makes it easy to build HTTP services that reach a broad range of
clients, including browsers and mobile devices. ASP.NET Web API is an
ideal platform for building RESTful applications on the .NET
Framework.
There is also a table detailing when you should use which.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'd like to get peoples thoughts on a scenario I'm about to encounter.
I've been tasked with building a RESTful Web API Service that will be used by two client applications.
One client application will be a web application and the other client will be a mobile application.
They are two distinctly different applications that are targeting the same data-store. I imagine that a lot of the requests made by both client applications will be of shared interest.(They may want to receive slightly different messages back in terms of the model objects they request).
But ultimately there will be differences, and I don't want to expose parts of the service that are designed for an individual client app to all other clients.
I've been looking at Versioning with ASP.NET Web API, where i can create the same controllers multiple times and create custom constraints to controller selectors that switch out the controller depending on the version used in the URI.
Is this a good idea in my scenario, or should i really be building two API's, one for each specific client application?
First of all, if you want client A to access certain resources while client B shouldn't, you're going to implement authorization like OAuth2.
In the other hand, I doubt that the solution should be implementing 2 different APIs or overcomplicate the code of a single API to return the same response with some differences.
Furthermore, you can emit same DTO for both clients and map the generic DTO to a domain object or other DTO using AutoMapper in order to avoid the hassle to manually set properties from one object to the other.
Finally, you can also use an OData interface to your RESTful API to let the client decide which properties you want to return in your entities or perform other operations during the request and get just what you need in each case.
Conclusion/summary: you shouldn't adapt the REST API to your clients, but the clients should adapt themselves to how the API works. At the end of the day, you're returning JSON entities and you can map them to any class even if the structure is different using AutoMapper as I said in the first paragraph. You can even implement a custom serializer if needed. It will be less pain than duplicating the server code because some differences.
What would happen if you add a third client and says "I want also a different structure in returned entities", add even a fourth one! You're going to get crazy, aren't you?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
today I started reading about Microservice architectures - and it seems to be very interesting!
But I have one doubt I need some explanation on:
Assume I want to create a blog and would build 4 microservices for that: User/login Service, Article Service, Comments Service and Reporting/analytics Service(not a realistic example, I know...).
The Reporting/Analytics service is purely backend - no issue here for my understanding.
But the three others involve some UI part - and as to my understanding this UI part should also be part of the microservice itself, right?
How would the UI integration work? Would I then have a 5th "front door" service that collects the user requests, forwards them to the other services which then answer with HTML/CSS and the front door service would then compose the individual responses into what is returned to the user?
Any chance, you have an example/use case for such a scenario?
Thanks and regards!
From my experience, in a microservices architecture, it is often useful to have a service that acts like an API gateway that front loads to the more domain specific microservices that does the work. The responsibility of the API gateway could be to aggregate results and return them to the front end but consolidating responses that are returned from the microservices would be coupling the knowledge of the two services and leaking some domain knowledge into the API gateway layer. The API gateway should probably be as thin as possible and should reach out to services to accomplish something.
The use case here that you're describing would be trying to authenticate the user before reaching out to the login service and then the article or comments service. Altogether the front end would still stay monolithic if they are a part of the same application.
If the application becomes big enough, the application would be separated by products but probably still rely on a core set of services. In that case, they would probably live in different UIs so that would make it less complex (kind of like microservices on the back end). Just as a side note, that a microservices architecture usually introduces a set of core services that can be utilized by different teams and therefore different applications that have different UIs. An example being an ecommerce application, that has customer service department editing orders for servicing customers and customers using an orders service to make purchases. In effect, these are two applications and they will have two different UIs. Hope this helps!
The other thing that I'd like to point out is that a microservices architecture is only great when the application becomes too large and complex. A microservices architecture requires more resources as it has some additional overhead. Start with a monolithic first :).
There are a couple of different approaches that you can take. If it makes sense each microservice can have its own pages that it can render. Then you only need a front end that can create the appropriate navigation for the involved services. The menu is built for the application, each service presents its own UI. This approach works well when you need to have the ability to include or exclude services from the application, for instance, based on licensing.
Alternately, each microservice can provide a set of HTML Fragments. Then you need a front end service to compose the pages and navigation. The fragments must all use the same vocabulary for CSS or whatever means you use to define the look and feel. This approach can lead to odd pages when HTML fragments are composed without one or more service that might be included.
Finally, a complete application UI can be built on top of the microservices. This can result in a "tighter" UI with a better flow. It also will typically take longer and be more difficult to change as new services are added.
What is the best? As with most cases in software development, it depends on what you are building. In the case of the Blog application, you described I suspect that each service could have its one full page UI. More commonly having a full UI is the approach I have seen. The HTML Fragment approach is more versatile but takes longer to develop initially. Once it is built though you will have more flexibility in how you deploy your application. This could be a real benefit for a Software Product company.
Hope that helps.