I'm trying to integrate with Priority REST API and using
https://prioritysoftware.github.io/restapi/#Service_Root_URL for this.
But when I'm trying to call some API's (for example https://www.eshbelsaas.com/ui/odata/Priority/tabmob.ini,3/usdemo/ACCOUNTS) I'm getting the error - API cannot be run for this form.
May someone explains to me what does exactly this means? Is there some permission problems?
This message says that the system administrator hasn't exposed this form in Odata.
accoding to https://prioritysoftware.github.io/tryit (which is not working currently), only few forms were enabled: ORDERS, CUSTOMERS and AGENTS
Related
Our setup is an on-premise Exchange Server which is accessible over the graph api. https://learn.microsoft.com/en-us/graph/hybrid-rest-support
We run in the issue, that our token is only "partial" working. And a token created by "Graph-Playground" is fully working. But we can't find any difference.
When I use Graph-Playground or use the token generated by Graph-Playground => all requests are working
When I create a token (over my app registration) => only some requests are working
The token seems to be valid some calls like /me are working, but all calls related to exchange like /me/contacts are failing with this error
Request, they work with token generated by Postman:**
Error:
{ "error": { "code": "MailboxNotEnabledForRESTAPI", "message": "REST API is not yet supported for this mailbox." } }
(that's a very generic error, and mostly don't say anything about the real issue)
Token Generation:
I create my token on the same way as Graph-Playground create the token (OAuth - Implicit flow):
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=token&state=test2&client_id=????&scope=openid%20profile%20User.Read%20email%20Contacts.Read&redirect_uri=????
Token - Analysis:
As a side note, it was working for a few days, nobody changed anything :)
So I have no idea, why the "Graph Playground" can create a working token, and my token only "partially" works. Can you help me?
There is already a thread, but I'm not the owner of it. Also there are no more responses... I can't provide a bounty for a foreign thread, that's why I create a new thread. You can find it here:
MailboxNotEnabledForRESTAPI - Microsoft Graph API integration with HMA Enabled on-premise server
I recognize your error, we see it in several cases (for Office 365):
User has no Exchange license (probably not the case, since it works in the explorer).
Customer tenant has setup additional security.
You can limit applications to certain mailboxes. Maybe there is some kind of setting or policy like this on your local Exchange as well, you have to connect to Exchange Online Powershell to set it, so maybe you can find something there. This is just a wild guess.
To track down this issue I would start checking the local Exchange logs.
Have you tried using the /users/{upn}/calendar endpoint? Maybe it's just that the /me/ part doesn't work.
I am working on plugins for a web platform.
I have one Core plugin(core library which is required to be installed and enabled) and one functional plugin.
I want when Core plugin is installed but not enabled then the functional plugin not to work. I've always check whether the Core is enabled and want to return it for all kind of requests - json, xml, html, ...
I want to return to the client response with good error code but not sure which one is the best.
I am thinking about 403 or as most people do 500.
Any suggestions?
Regards,
Boris
The returned code you should use really depends on semantics of the resource state. The answers to these questions should determine appropriate status code:
Why the Core is disabled? Is it an error state (something unexpected, that should not happen under normal conditions) or normal state?
Is the service disabled for all clients or some authorized users could perform the calls?
Should the client treat current state as temporary or permanent?
Here are some suitable error codes (under certain conditions):
403 Forbidden
You should use this code only if some of the users still could call the service successfully.
500 Internal Server Error
This generic error code is far too overloaded. Choose it only if you can't select more specific error code.
503 Service Unavailable
It's a good candidate if current state is temporary and should be fixed soon.
I am using this example: https://github.com/ajimix/asana-api-php-class/blob/master/examples/oauth.php to learn how to use the asana's oauth. I already registered my app on the asana's developers webpage. But, when I get the asana's response with my 'redirect_url'?code=0%XXXXXXX, localhost gives me a 500 status. I don't know why, does anyone know how I can solve it?
I tried using the other examples in there: https://github.com/ajimix/asana-api-php-class/blob/master/examples/, but I wasn't able to make them run either, I always get a 500 status. I think that the problem must be in my server, but I don't how solve it. Maybe changing something on the .htaccess file, but I don't really know what to put in there.
If you're looking to use the Asana API from PHP may I recommend the official first-party client: https://github.com/Asana/php-asana
It also contains examples of how to use with OAuth and is officially supported by us at Asana :-)
We have two jira installations at our company. One that we use for our projects and a second one for testing purposes.
I'm working in a project that needs to use the JIRA REST API. For this purpose I'm connecting to our testing instance.
The problem is that while trying out the REST API, I keep getting 400 errors without a single explanation of what went wrong. I just get an HTML with
Your browser sent a request that this server could not understand
I was a bit desperate and decided to try it into our real JIRA. To my surpirse the same request gave me a different response:
{"errorMessages":[],"errors":{"project":"project is required"}}
In this case, I do get a meaningful error!
I replicated this easily. I would never get a meaningful error from the test instance, but the real one will always give me one.
I cannot keep trying out stuff in our productive JIRA, but I cannot easily continue working without getting meaningful errors. So, what could be wrong in the testing instance? I could not find any configuration about the 'verbosity' of the API responses.
I believe that this error is returned not by JIRA but rather by proxy web server that is part of you production configuration.
I suggest you to compare HTTP headers that are sent with working requests from your browser with headers you pass via curl. Googling for the "Your browser sent a request that this server could not understand" helps too
When I make API calls to the server, I'm getting 404 errors for various data -- grades, role IDs, terms -- that I won't get on the next time I call it. The data's there on the server, viewable by the same user, and is often returned successfully, but not every time. The same user context will return data successfully for other calls.
Any ideas what could be causing this?
I'm using the Valence API with the Python client library and our 9.4.1 SP18 instance of Desire2Learn in a non-interactive script.
more detail: the text it returns on the bad 404s is " ErrorThe system cannot find the path specified."
It would help enormously to gather data about your case: packet traces that can show successful calls from your client alongside unsuccessful calls, in particular, would be very useful to see. If you are quite certain (and I see no reason you shouldn't be from your description) that you're forming the calls in the right way each time you make them, then the kind of behaviour you're noticing would seem to speak to some wider network or configuration issue: sometimes your calls are properly getting through the web service layer, and sometimes they are not -- this would seem therefore not to be down to the way you're using the API but in the way the service is able to receive that request.
I would encourage you, especially if you can gather data to provide showing this behaviour, to open a support incident with Desire2Learn's help desk in conjunction with your Approved Support Contact, or your Partner Manager (depending on whether you're a D2L client or a D2L partner).