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?
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.
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
I want to migrate from wcf rest services to web API, (around 30 endpoints to be created with 6 complex methods) just want to decide based on the budget (1 month time with one resource) available, which amongst the below would be a better solution.
Writing whole new code for creating web API, just utilizing logic already present in wcf rest services.
Creating API endpoints and calling wcf services inside that.
There is no real way to tell for sure without knowing more details (or maybe the entire project).
If you're not sure the time will be enough, one thing you can do is to start with option 2 and then replace each endpoint with the actual code from the WCF service. If one month proves to not be enough, you may end up with a mixed solution (where some methods are implemented in the Web Api and some are wrappers calling the WCF service). However, you will be able to just keep slowly moving the methods back to the Web Api and finish it eventually.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am a .Net Developer. I jst want to know that why The Repository Pattern and Unit of Work in MVC and EntityFramework is Used. Plz tell me the scenario where I can use Repository and Unit of Work Pattern.
OK - First, the Repository Pattern. Why? Imagine the scenario where you have a database in your application - say, SQL 2000. You then want to upgrade the database to SQL 2008 and Entity Framework. If you don't have a Repository pattern implemented, this could turn out to be very tedious. Why? , well imagine that the data access is implemented using ADO.net. Very different from LINQ to Entities. So, the ADO.NET code would be littered through your data access calls.
Now, if your application used a Repository Pattern, it would call, for example, the GETCUSTOMER() method in the Repository. It does not care how GETCUSTOMER() gets its data, because its DECOUPLED from the actual data access. It only goes as far as the Repository. So, when you rip out your ADO.NET code and replace it with Entity Framework Data Access technology, you don't have to mess with the application, only the data access stuff.
UNIT OF WORK: Imagine this scenario. A Customer has just registered on your site. 1.You need to add their data to an Accounts section. 2.They have also subscribed to the newsletter. AND, 3. you need to send them a confirmation email to activate their account. These 3 thing ALL need to happen to successfully register a new customer and can be considered a UNIT of work. It has some parallels to a database transaction.
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.