Documentation HTTP API describe manipulation with applications
For exmple how to get binded rules:
https://api.voximplant.com/platform_api/GetApplications?...&with_rules=1
But how I can bind exists rule to exists application via HTTP API?
As I see rules can not be unbind and to bind to another application or binds with few applications simultaneously...
Rule is pretty simple thing, so you can just use /AddRule and /DelRule to manipulate them.
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).
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
I’ve read the Parse documentation regarding custom domain names, and I understand that I can host web content at a custom domain name.
Is it also possible to use the Parse REST API, or Cloud Functions, via a custom domain name?
Example:
https://api.myshoewarehouse.com/v1/shoes/
instead of…
https://api.parse.com/1/shoes/
Looks like it is not allowed by parse.com directly. The only way to do it is to configure proxy server somewhere on your machine, like here.
Another way is to set api.myshoewarehouse.com domain record to CNAME pointing at api.parse.com. But then you need to:
ignore certificate check, e.g. with curl -k option, which obviously isn't safe thing
forget about changing URL path (e.g. /1/shoes/ can't be changed to /v1/shoes/)
I have a RESTful API which accepts all of the standard verbs, including PUT and DELETE, however most web browsers don't support PUT and DELETE in their native FORMs.
Is it possible to use my existing .htaccess to rewrite a GET request with a specific variable (&METHOD=PUT) to use the PUT verb so that my code is not required to work around this limitation in the browser?
No it is not possible to do that using rewrite as rewrite engines are for rewriting URLs while to convert request types(GET to POST for example) one needs to change message header/body.
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.