Suppose, I am building an eCommerce service API with two types of users. One of them is marchet, who will sell products in the service, and another one is the customer. Most of their functionalities are different. Should I build different endpoints and controllers for their common functionalities like login and register?
What is the best practice?
Related
Context
Let's imagine a simple microservices architecture (e.g. 2-3 microservices). Microservices are domain-based, API gateway in place and everything is how it should be. At the same time, microservices APIs are consumed by public mobile applications, admin UI, and other services for S2S communication, hence, we have three possible APIs consumers. Depends on the consumer, response DTOs are different but the business process might be the same (e.g. response for GET /users endpoint has different DTOs for a consumer application and admin UI but technically the data is taken from the same DB).
Question
How do you segment APIs in that case? Do you use namespaces like external, internal and etc?
Also, feel free to share your experience of how you segment APIs.
Thanks in advance!
From my point of view, the APIs should be different depending on the type of consumer that is going to use them.
For example, talking about your use case, It couldn't be the same API one that is intended to provide simple user information that the one used by an administrator. You should define two different APIs in this case, with different paths like internal/users/ and external/users as you said, and internally these two endpoints can use the same logic.
This separation is not only good in order to return different dtos in each endpoint but also to define different security (authentication/authorization) mechanisms for each API because I suppose that these requirements will be different for an admin API that for a general user one
It depends a bit on the philosophy you want to adopt.
The one suggested by #JArgente is good, in that you'd get good separation, and the role of each is (or at least should be) very clear.
The other approach is layering, which (for the OO programmers out there) is a bit like developing overloads for a method. It assumes that the data required by the derived API's is provided by the base API. So:
Develop a base API that provides all the data this API family needs to provide. This API might be the one that internal users use (e.g. Admin User), and it could require authentication.
Develop a public facing API that consumes the base API. This one would be your public-facing one.
Each API has a separate API Spec; depending in how you do this you can leverage inheritance at the Spec level.
Each API also has an actual endpoint which triggers some sort of processing - e.g. logic within the API Gateway itself, or logic handled within a downstream component like a microservice.
The public-facing one can be anonymous, as long as something (e.g. the API Gateway) can make an authenticated call against the base API, using some kind of 'service account'.
The advantage here is that you still get good separation between different API's and their consumers, but you also get the advantages of inheritance, so that code duplication is reduced (testing effort isn't so diffuse, etc).
This approach also allows you to run the endpoints on the same API Gateway, or deployed on separate ones (internal vs external).
I have currently delivered a SPA (Vue.js) web application with a Java API backend. Everything is currently sitting in AWS, with the frontend being in CloudFront and the backend in ECS connecting to a RDS instance.
As part of the next phase of delivery, we are creating a B2B API. My question is that of architectural design and deployment strategy, is it commonplace to just extend the existing API with B2B functionality? Should I keep them both separate with an API gateway in front? We envisage that the B2B use eventually will outgrow the SPA use case so the initial deployment configuration needs to have the most flexibility to grow and expand.
Is there some sort of best practice here? I imagine that a lot of code would be similar between the two backends as well.
Thanks,
Terry
First off - Deciding on service boundaries is one of the most difficult problems in a service oriented architecture design and the answer strongly depends on your exact domain requirements.
Usually I would split service implementations by the domain/function as well as by organizational concerns (e.g. separate teams developing them) and not by their target audience. This usually avoids awkward situation where team responsibility is not clear, etc. If it will grow into a very large project there may also be a need for multiple layers of services and shared libraries - And at that point you would likely run into necessary re-factorings / restructurings.
So if there is a very large overlap in function between your b2b and the regular api you may not want to split the implementation.
However, you may also have to consider how the service access is provided and an API Gateway could help with providing different endpoints for the different audiences, different charging models, different auth options, etc. Depending on your exact requirements an API Gateway may not be enough and this may also require another thin service layer implementation that uses common domain services.
In my company, we develop an API which is consumed by external customers. We want our API to evolve in a backwards-compatible way without using versions.
We would like to have tests on our side that validate that, whenever our API evolves (e.g. new attributes are added to requests or responses) backwards-compatibility is guaranteed. What is the best way of validating that?
I've had a look at contract-testing (Pact or Spring Cloud Contract) but they seem particularly effective in consumer-driven testing - which is not what we want to do.
I did laravel RESTful app, and now I'm creating frontend with vue.js. But I dont understand this part:
If pages on the frontend requests products, categories and main information (like phone, email etc), this should be provided in different requests to the API? In this example, it will be separate request for products /api/products/get, categories /api/categories/get and like this? Or should I separate data for pages on backend and my API will return all of needed data with /api/get/mainpage?
Well, imho best practice will be to use endpoints related to data (e.g. /api/products/get).
It will ease your life because in this case you will need to write API once. And then just combine needed endpoints in requests for your frontend pages.
So if you will have to change your frontend, you won't need to change the backend.
Both parts become as independent as possible.
The definition of an API seems very broad and I don't understand whether an API is the link that connects different software or whether the server that provides data like how a airport company provides fight information to a website is the API.
Could it be both?
It can be both. In practical terms, the most common way two pieces of software interact with each other is through APIs. The two pieces of software might be living on the same computer (e.g. an App using services provided by the OS). They can also be running on different computers separated by internet.
APIs often consist of classes and methods/functions. For a given API method/function, in general it does one or more of these 3 things:
retrieve information
store/update information
perform an operation
For example, an airport company runs a server exposing REST APIs that provide flight information. A client (e.g. a smartphone app) calls that REST API to retrieve flight information.
API spec defines a contract - the exact semantics on how caller calls the API. e.g. method names, parameter types and expected values.