I'm getting the following error when trying do a put to customer endpoint
"System contract version 1 for endpoint BI/100 does not support REST"
any idea what this error means and how to fix it?
This error means precisely what it says: you are trying to perform REST operation against a Contract-based endpoint that does not support REST operations. Acumatica has a notion of "system contract version" (which can be seen on the Endpoint Properties page on Web Services Endpoint screen), and at this point only system contract version 2 supports REST operations.
There are two ways of getting system contract version 2 endpoint - either by extending an existing system contract version 2 endpoint, or by creating a brand new endpoint in the (recent version of) Acumatica. To expand on the latter, Acumatica always creates new endpoints with the latest available public system contract version (which is 2 at the moment).
Related
Case: Google Chat support in node.js using the googleapis library.
I studied the documentation, created a service account and implemented authentication. In first step I used the chat.spaces.list() method and it worked (no error returned).
I want to send a message via chat, so I wanted to create a new space, I found the chat.spaces.create method (https://developers.google.com/chat/api/reference/rest/v1/spaces/create) Unfortunately, this method is not present in "googleapis" for node.js In general, I see that the list of methods in "googleapis" is different than the one in the documentation. Only spaces in the documentation, but spaces and rooms in the library... I'm lost. How to do it? Any tips?
I see that the list of methods in "googleapis" is different than the one in the documentation
I think you are seeing wrong documentation. Your reference link is REST API documentation. The nodejs googleapis client documentation you can see on https://googleapis.dev/nodejs/googleapis/latest/chat/classes/Resource$Spaces.html.
And also based on the REST API documentation, the API that you looking for(create space) is not general available.
† Supports user authentication in Developer Preview. App authentication isn't available.
You need to join Google Workspace Developer Preview Program to access that feature.
There are many excellent resources about the Unit of Work pattern. My understanding is that it's main purpose is to provide a way to ensure that the effects of a piece of code will not persist if an error occurs. There are plenty of examples of this usage for databases in most languages.
There are very few resources I can find about using such patterns to query and use external APIs while maintaining some level of data integrity during an error. Generally repositories are about data persistence but a lot of API's do concern such things especially in a microservice architecture. Clean Architecture: Where to make API calls suggests that such a microservice architecture should abstract calls to other microservices using a repository, and there are many public APIs that can be thought of in a similar manner.
In my specific case, I am looking to plug in the Todoist API for Task items into my application which works with its own version of a Todo entity. I have successfully adapted my TodoRepository for the Todoist API and can see my tasks from Todoist displayed in my UI - I now face the issue that if a call fails then I could be adding, deleting or updating a Task in the Todoist API when an error occurs after the call, which is not ideal for data integrity reasons.
There seems to be some distinction between an API that can act as a repository and one that cannot. Seemingly, if the API is able to perform general CRUD on a similar entity in the modelled entity then it may be a good candidate for a repository adapter, but if it were something like retrieving the weather forecast, determining if a name is the same as some celebrity, working with the google maps API (if your application wasn't a map itself), etc, then these are handled differently.
Under the assumption that I have not yet confirmed that all API adapters/facades will be implemented in the Infrastructure layer of a project, what context does the interface that defines the API usage exist? If I want to query to see if a name is also a celebrity name, would I have an Application or Domain service interface that looks something like
public interface CelebrityService {
Celebrity LinkNameToCelebrity(string first_name, string last_name);
}
Where Celebrity is a Domain entity. This feels out of place if the Celebrity entity has been made only for this call.
Similarly for a weather API,
public interface WeatherService {
Weather GetWeatherForDay(datetime day);
}
I'm trying to use the Assistant2 APIs inside my Web Application (Angular CLI project) with the ibm-watson library and the suggested Webpack Configuration.
But at runtime I get different CORS policy errors calling the Assistant2 APIs.
So it's possible to use the Assistant2 APIs via browser?? Or calls must be all made server side to avoid the CORS policy errors?
Well, Watson Assistant provides REST API that can be called from anywhere where there is access to IBM Cloud (which bacicaly means access to internet) - so from browser as well.
Now, while you can call the Watson Assistant REST API directly from the client-side browser, sometimes it might be beneficial to have a server doing the actual call as when you call the REST API from the browser then the user has access to the request and the response from the system. This means the user has access to context part of the dialog response which in some cases might not be desired (depends on the stuff that the author is storing in the context).
i would like to ask your help in relation with one issue i am facing. So basically i defined a swagger 2.0 spec for an API, and on the operation's responses i used the schema property in order to reference some definitions for objects that reflect the responses structure. I validated the spec on the Swagger Editor, and it is valid, and also if i generate the client code, using Swagger Codegen, the client app works well consuming the API. Now, the problem is. I went to the Developer Portal and on the API's details page, i checked the API definition (Open API option) and i compared the spec with my original spec that i used to import the API on the API Management service. And i noticed that the schema property is missing, so it is not referencing the schema of the response. Any idea?
Thanks
I figured out the issue. Apparently using the schema property on the responses, according to Swagger 2.0 spec, you can use nested $refs, in order to reference definitions inside each other. But apparently, it is not possible for Azure API Management Service, since it is mentioned as a limitation in the following link: API Management - API Import restrictions.
Anyway, i will try to change my API's spec in order to avoid nested $refs and workaround the issue.
Thanks
I am trying to import an API I have into Azure API Management using swagger, should be fairly simple but I always get the same error:
One or more fields contain incorrect values: API with specified name
already exists
I do not have ANYTHING setup in Azure API management yet, very frustrating.
UPDATE
I am using Swashbuckle (https://github.com/domaindrivendev/Swashbuckle) to add Swagger to my WebAPI project.
It is generating Swagger 2.0 docs.
Here is the info element of the Swagger Doc:
swagger: "2.0",
info: {
version: "v3",
title: "ShopZioAPIv3"
},
It does not matter what I change that to, I still always get:
One or more fields contain incorrect values: API with specified name
already exists
I my case the title {"info":{"title": "API-NAME",... in the Swagger file did not match the name of the selected API (because we had created several test APIs).
Simply changing the string value fixed it.
That error message appears when you don't specify a unique API prefix.
I realize that you said that you don't have anything already already setup in the API however, if you could try putting some unique value in this field:
An API Management service instance is designed to host multiple APIs, so the prefix is used to differentiate between the APIs by using the first part of the path.
The subdomain part of the URL is used to identify the service. e.g.
http://{servicename}.azure-api.net{/api-prefix}/path/segment?param=value
Update
Based on the provided Swagger, the problem comes from multiple operation objects with the same OperationId. This is invalid swagger.
Usually Swashbuckle will fail before generating operations with duplicate Ids. There is a ResolveConflictingActions method that allow you to put your own code to deal with these cases. It seems like in this case the resolution code is not doing the right thing.
The Azure API Management error, "API with specified name already exists," can be misleading, and in this case, it is inaccurate.
As discussed in Darrel Miller's answer, invalid Swagger can cause this issue. Although multiple operation objects with the same OperationId is invalid in Swagger 2.0, I think the core issue you are having is that Azure API Management does not yet support Swagger 2.0 (as of Dec 1, 2015).
Swashbuckle 5+ generates only Swagger 2.0 so some,if not all, definitions generated with it will fail with this error -- even well-formed Swagger definitions validated by http://editor.swagger.io, which also seems to only support Swagger 2.0.
Swashbuckle 4.2 supports generating Swagger 1.2 definitions.
Also, I was able to take my Swagger 2.0 definition (generated by Swashbuckle 5), and convert it to Swagger 1.2 using Restlet Studio.