I am using ABP v3.3 on ASP.NET Core 3.1 in a microservice environment.
We are wanting to prefix our microservice routes with the service name.
E.g, accounting service would be:
/accounting/api/invoices
/accounting/api/payments
This is fine with our own controllers as we can define the route with route attributes. E.g [Route("accounting/api/invoices")]
However for internal abp routes like
/api/abp/api-definition
where the controller is defined in the Abp module with these route attributes already applied, how do we go about adding this prefix?
I can’t find anywhere in the documentation anything relating to this, except for the case of conventional controller creation which is not applicable here.
The above is to support the scenario where all microservices are behind an internal load balancer, and all /accounting routes should forward to this single service. This is troublesome currently when using IHttpClientProxy for service-to-service requests, as the /api/abp/api-definition request needs to be forwarded to the specific microservice.
The only alternative approach I have found is to set root paths for all services as http://<loadbalancer>/<servicename>, and then in each service add the line
app.UsePathBase("/accounting")
which strips the above path from the requests to enable route matching.
This however does cause additional issues with the generated Swagger docs from showing this additional route path, which can become confusing.
Any help appreciated
yes but not recommended because you need to replace several code parts.
for example
https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Http.Client/Volo/Abp/Http/Client/DynamicProxying/ApiDescriptionFinder.cs#L94
https://github.com/abpframework/abp-samples/blob/master/MicroserviceDemo/gateways/BackendAdminAppGateway.Host/BackendAdminAppGatewayHostModule.cs#L126
https://github.com/abpframework/abp/blob/dev/modules/blogging/src/Volo.Blogging.HttpApi/Volo/Blogging/BlogsController.cs#L14
Related
I am learning express and the http methods, but I cannot find any documentation on it. Is /api/value just for the json data, like an address just for that data? Just any extra info on it would be appreciated. Like what exactly does it do and if there is any documentation from express about it. Or is this a global term used in urls throughout frameworks and the internet?
For example:
app.get('/api/jackets'(req, res) => {res.send('logic')})
Why do we need to add the api before jackets and what does it do?
It's not necessary, it's used only for a better understanding
The /api request is not required, but putting a prefix in front of the API requests such as:
/api
or, in some cases including a version number:
/api/v1
Allows you to use the same web server for more than one type of request because the /api prefix uniquely identifies each API request as an API request and it can easily be routed to where you handle API requests. You could have plain web page requests from a browser served by the same web server. While, you don't have to use such a prefix, using it gives you the most flexibility in how you deploy and use your server.
Similarly, putting the version in the prefix such as /api/v1 allows you to evolve your API in the future in a non-backward-compatible way by adding a new version designation without breaking prior API clients (you support both versions at the same time - at least for a transition period).
When using history mode in vue-router the documentation is suggesting a pretty dodgy way to get around some of the limitations it has.It suggests a server-side configuration that catches all URLs that could be a client-side route and rewriting to root (/) so the client-side app is delivered. And then another catch-all route to a 404 component in the client-side router if no routes match.
Problem is, this will mean your server is returning 200 OK status codes to crawlers/indexers for basically every URL, specifically ones that don’t technically exist.
My thoughts so far:
Use IIS <rewriteMap> to list the valid client-side route patterns I have and use that for matches instead of a catch-all on everything not a file/dir.
Problem: pain to manage in tandem with client-side routes.
Routes defined in server config and handed to client-side router via an api endpoint for registration
Problem: setting up an API when you just want to host a static app is a pain.
Any other suggestions?
Let's say you are using an API gateway like Apigee or Amazon API Gateway and your public address for your API is http://my.public.dns.com/path/v1/articles. This gets routed through your gateway to an internal host http://some.internal.host.com/v1/articles. Now if your internal API returns relative links to itself then when they get served to the client they will be incorrect as they are based on its path not the actual public path. I know I can resolve this by transforming the response using the tools available in the respective gateway.
The question I have is; is there a standard way for a gateway to communicate the public path to the downstream component? I was thinking there might be a similar HTTP header to X-Forwarded-For.
There is no standard similar header.
Note that I think you mean if the back-end returns absolute links. If the links were relative, they'd already be correct. Relative links use no leading / thus are "relative" to the current directory -- whatever it may be - and so any external prefix is retained by the browser and the links transparently remain valid. Relative links can also backtrack a directory level with a ../ path prefix for each level.
Note also that API Gateway doesn't require any path prefix if you're using a custom domain name for your API This necessarily limits you to deploying a single "stage," but that's a reasonable tradeoff for a more flexible path... so the easiest solution might be to use a path in your API matching those internal paths.
We are building a fully RESTful back-end with the Play Framework. We are also building a separate web front-end with a different technology stack that will call the RESTful API.
How do we deploy both apps so they have the same domain name, with some URLs used for the backend API and some for the front-end views?
For example, visiting MyDomain.example means the front-end displays the home page, but sending a GET to MyDomain.example/product/24 means the back-end returns a JSON object with the product information. A further possibility is if a web browser views MyDomain.example/product/24, then the front-end displays an HTML page, and that webpage was built from a back-end call to the same URL.
Finally, do we need two dedicated servers for this? Or can the front-end and back-end be deployed on the same server (e.g. OpenShift, Heroku)
You are gonna to dig yourself... deep :)
Simplest and most clean approach with no any doubt is creating a single application serving data for both, BE and FE, where you differ response (JSON vs HTML) by the URL, pseudo routes:
GET /products/:id controllers.Frontend.productHtml(id)
GET /backend/products/:id controllers.Backend.productJson(id)
Benefits:
single deployment (let's say to Heroku)
name space managed from one app
No need to modify the models in many apps after change in one of them
else if
If you're really determined to create a two separate apps, use some HTTP server as a proxy - for an example nginx - so it will send all requests to domain.tld/* to application working at port 9000 (which will answer with HTML) but requests to domain.tld/backend/* redirect to application working at port 9001 responding with JSON.
else
If you are really gonna to response with JSON or HTML depending on the caller you can try to compare headers to check if request was sent from browser or from AJAX call in each controller , but believe me that will become a nightmare faster than you thing... insert the coin, choose the flavor
I thought of a different solution. I'm going to deploy back-end to a subdomain like
http://api.myapp.example/
and deploy front-end to the main domain:
http://myapp.example/
but I think you'd better use 2 different hosts, one for front-end and one for back-end (I searched the Google and this was the result of my investigations
Other possibility (therefore as separate answer) is using a possibility added in Play 2.1.x a Content negotiation I think it's closest for that what you wanted to get initially :)
Indeed its much easier to create a MEAN STACK APP and use one hosting like Heroku for instance.
Your frontend is what it is, front end for your backend. It will be easy to access backend / restfulAPI's and frontend like this:
http://localhost:3000/api/contacts (to access and consume your API endpoint)
http://localhost:3000/contacts (frontend)
NB: localhost:3000 or http://yourapp.example/api/contacts (api)
http://yourapp.example/contacts (frontend)
It's in the URL
I've been looking at backends and APIs for a while now. It seems that sometimes devs will build a regular backend (in say a language like PHP) that handles all the backend matters and sometimes devs will instead choose to build out their backend through an API and then use their own (and possibly other) sites to pull data from this API.
I was wondering this:
Say I want to build a regular backend using a server-scripting language like PHP, which I will use to not only render my main website, but will also allow me to do other server-side scripting etc. Then say I want to use this data from the current site and make it accessible to another site of mine through API calls. Will it be possible to build an API on top of a regular backend?
If the answer yes, how complex can it get to achieve something like this?
What tools or design strategies (if any) would you have or have used for achieving this?
This is an old question, but since I'm here, I may as well provide an answer for anyone wondering. Joe is asking about server-side web APIs versus regular server-side code.
Yes, you can have a "regular" backend and an API backend exist at the same time. If your backend is in PHP, you can refactor and extend your code to handle API requests.
Like Patrick Evans said, an API is the backend. If your backend PHP code communicates with a database to manipulate or retrieve data, then you can consider this an API transaction. Whenever your backend receives a request, evaluates/actions that request, and returns a response, it is essentially acting like an API.
Let's say you own example.com, with an index.php file in the root directory - so when a user requests example.com in their browser, this index.php file is processed and served to them. Now, you can set up this index.php file to handle both regular page requests (i.e. the php script returns an html template that is rendered by the browser) and API calls. This can be as complex or as simple as you want it to be.
The best way to handle this would be to assign different routes for rendering your main webpages and API calls. You can set up routes in the following way...
example.com/index.php?route=api&data=users can be handled by your 'API code' in index.php to return a JSON response containing a list of all the users in your database, while example.com/index.php?route=home will just return your website's home page.