Good Afternoon,
I have a situation where three swagger files will have different resources but they belong to the same domain. And I can't merge them into a single swagger as we have many such scenarios and managing of a single swagger and single api proxy will be a big over head.
For example:
I have 3 apis with the following paths and resources
/supermarket/v1/aisles/{aisleId}/itemcategories
/supermarket/v1/aisles/{aisleId}/itemcategories/{itemcategoryId}/seasonedvegetabletypes
/supermarket/v1/aisles/{aisleId}itemcategories/{itemcategoryId}/seasonedvegetabletypes/{vegetablestypeId}/apples
All the above 3 should be in 3 different swagger files, so I need to create 3 api proxies for the above.
Since the path suffix is same for all of them "/supermaket" the Azure API Manager will not allow to create another api proxy with the same path suffix as it MUST Be unique.
So to achieve this in Apigee Edge (Google Edge) api management product. I will have the basepaths as below
/supermarket/v1
/supermarket/v1/aisles//itemcategories/
/supermarket/v1/aisles//itemcategories/*/seasonedvegetabletypes
so that I can avoid the unique path constraint also achieve creating 3 api proxies.
But the Azure API Manager is not accepting the "wildcard" entries into the API Path Suffix field when creating the API Proxy.
Note:
You may suggest combining the 3 apis into a single swagger file might solve the issue but the example I gave above is only 30% of the swagger and we have many such paths that will fall into a single business domain so we must have them in different swagger files and different api proxies.
We should be in a position to deploy different API Proxies with the same path suffix by allowing wild cards or regex into the API Path Suffix.
Your help to resolve this is highly appreciated. Thanks.
At this point this is a limitation that can't be worked around. The only way to make APIM serve those URIs is to put all of them under single API, which is not what you want, unfortunatelly.
Related
I am trying to create api and expose them via APIM. The path of the api that I expect is
baseUrl/v1/Product/Upload.
But when i try to use versioning of APIM, I could only come up with something like
baseUrl/Product/v1/Upload, where Product is API url suffix.
Is there a way in APIM to change the order in which version number is placed in the url path.
Every API Developer will have their own requirement of versioning. So Azure API Management provide several options instead of a single approach to versioning. And Path-based versioning is one of those options.
If you check this Path-based versioning section of Microsoft document then you will find -
When the path versioning scheme is used, the version identifier needs to be included in the URL path for any API requests.
The format of an API request URL when using path-based versioning is as follows.
https://{yourDomain}/{apiName}/{versionIdentifier}/{operationId}
It is recommended to follow this format but if you want to modify it you can use the API Management transformation policies. The rewrite-uri policy converts a request URL from its public form to the form expected by the web service.
Read this Rewrite URL and Policy Expressions in Azure API Management document for more information.
When creating a new activity, input and output parameters are not separated as it was need in v2. How does the design automation service distinguish between them?
Is it via the verb? I hope not, because sometimes there are poorly designed Rest-APIs or GraphQL endpoints that require a POST request for receiving data.
You are correct!, it is via verb - based on type of verb, Design Automation service takes an action if it requires to download the resource (get) or upload the resource (put | post) etc, V3 also supports other types of verbs like read, patch etc.
I have 2 different restful api-s, and I would like to use Tyk for gateway.
My plan is to have a common url (like: http://viktorservices) which can towards messages to those two api endpoints.
For example, the first api is a user manager api, and has an endpoint:
GET: http://localhost:8080/usermanager/users
And the other api is a car manager api, and it's endpoint:
GET: http://localhost:8081/carmanager/cars
Is it possible somehow, to upload a Swagger JSON for the Tyk Catalog (For developer portal) to be able to se only one API called: User and Car Manager?
And when I click on "View Documentation" in Tyk's developer site, all of the endpoints from both APIs are visible, grouped by their main API names?
I tried to put the two swagger jsons into one as an array, but then it is not visible on the Developer Site.
I am able to upload the swaggers one by one, but then I will have two API-s on the Dev site of Tyk.
I think the main point here is that developer portal documentation/swagger does not have to correlate with the actual APIs you have. Portal gets organized by catalogues/policies. So you can have multiple internal Tyk APIs, but expose them as the single catalog in Portal, by creating Policy which gives access to both APIs. So, just create new "public" swagger file for documentation purpose, which includes endpoints from both of your internal APIs.
Does it make sense?
I'm a noob.
I have been researched Amazon's DynamoDB and Google's Volley extensively, however it is still not clear to me whether these two technologies can be used together (even thought they both support JSON, for example).
I think my questions stems from Volley expecting a URL parameter to get/post data to. Does my AWS table have a URL?
In every DynamoDB API request except for ListTables, you must specify a TableName. The TableName, combined with your AWS_ACCESS_KEY_ID and region/endpoint allows the DynamoDB service to perform operations on your table on your behalf. Each region has a different set of HTTP and HTTPS endpoints. The table namespace of each region is distinct for each AWS_ACCESS_KEY_ID, so even if you have a table named "my_table" in us-west-1, that does not mean that you have a table named "my_table" in us-east-1. Even if you did have two tables with the same name in different regions, they would not necessarily have the same data.
To sum up, you want to use the DynamoDB endpoints as the URL to POST data to, and you will specify your credentials and table name as part of the body of each request.
Note that AWS requests are signed, so you may need to implement this logic and other boilerplate logic in your application if you use the HTTP DynamoDB API.
The AWS Mobile SDK for Android will create and sign your DynamoDB requests, and make the requests for you using abstractions of the DynamoDB API. For more examples, see the Getting Started section in DynamoDB of the AWS Mobile SDK for Android.
I am working on upgrading the synchronization layer for a web application with the box account and I am in the middle of the way and have some questions:
Is there a way to get the full structure for the folders and the documents with one request? My other solution it to make multiple requests for each folder to get its contains (folders and files)
Tags APIs in V2 is not yet added, is there a certain confirmed date to have it ready? Tags is important in our application.
Authorization, I am using the same values used in API V1 as a header (Authorization: BoxAuth api_key={0}&auth_token={1}) (one system account) without the need to use the refresh token to get a new authorization token every while. Is this going to work in the future?
Is there a way to call a service or web api on our web application side every time a user tried to delete a document from box to check if this document can be deleted or not?
Thanks
1) There isn't a 1:1 equivalent of get_account_tree in V2. You'll need to make recursive GET /folders/:id/items calls in order to get the entire folder tree
2) We will be adding tags in V2 but don't have a definitive date at this point.
3) No. V1 authentication will be deprecated along with the V1 API. You'll need to port your app over to using OAuth 2.
4) You may want to check into the /events API for doing this: http://developers.box.com/docs/#events-get-events-for-a-user