I noticed that some of the fields/attributes related to "Get Sheet" API has attributes like:
Not documented attributes
which are not documented in the API doc
https://smartsheet.redoc.ly/#section/Sheet-Object
Postman API response
Could anyone please help in knowing what exactly is the reason to this? Are these to be considered? What description do I consider for each of them?
Related
I have used this blog post to attempt to setup an endpoint to retrieve generic inquiry data but I appear to be missing something. Our default endpoint is on Contract 1 so I did not extend that endpoint, is that necessary to get this to work? We have another custom endpoint and I setup the generic inquiry as laid out in the blog post but when I make the PUT request via postman with the "$expand=Result" parameter I receive a 500 and exception error "The given key was not present in the dictionary".
I am not super familiar with Acumatica or generic inquiries but from that blog post and other resources my understanding is that in order to retrieve the results of a generic inquiry it cannot be setup as a top-level resource or else you will only receive 1 record. I am trying to retrieve the entire list of records.
Any help will be greatly appreciated!
Here is a screenshot of the setup:
The error message you describe usually indicates something missing with respect to the endpoint. Per the blog post - did you define the endpoint like this (which is the correct structure)?:
If you are not sure, please post a picture of what you created in your custom endpoint, and I will see if I can assist from there.
I've actually been working on the same thing, referencing the same article.
I am able to get it to work as described. One question, are you specifying the $filter parameter? I only get this error when I try to use a filter. I am able to call the new endpoint and get back full results.
I found your post searching for a way to use a filter or I trying to find out if there is anyway to pass parameters to the GI from the rest call.
What should be done if an invalid uri is provided when calling a REST Web API (asp.net mvc)? I'm getting
HTTP Error 404.4 - Not Found
The resource you are looking for does not have a handler associated with it.
When I provide an invalid controller, I get the following:
No HTTP resource was found that matches the request URI
'http://localhost:51929/api/usera'.
No type was found that matches the controller named 'usera'.
I thought 1) was the default and ok, but I've been asked to return a custom html page for both of the above and some others errors but it doesn't feel right to return a web page when dealing with an Web API?
1) Is this common practise?
2) Is there a best practice/standard?
Is there a best practice/standard?
One of the important points in HTTP is that the meta data of the response gives general purpose components the hints to support a coarse understanding of what is going on.
One significant piece of meta data is the response code, which communicates when the response body contains a representation of a resource, and when instead it contains a representation of "an explanation of the error situation".
Does it have to be a "web page"? No, of course not. Instead it could be text/plain, or application/problem+json, or any other representation that you would expect a general purpose client to be able to interpret.
The design of the message should be motivated by its use case, which is to say it is a document intended to be read by a human being trying to figure out what has gone wrong (we don't expect general purpose components to understand how to automatically fix a bad URL; instead, we describe the problem for a person, who will sort it out).
Right now I have a REST service which creates a report via a POST:
POST http://myhost/reports
The report however is not persisted, and cannot later on be retrieved via a GET:
GET http://myhost/reports/{id}
Instead I return the report immediately in the response to the POST. Am I violating any REST principle here, e.g. anything a POST creates should always be accessible via a GET, or is this setup OK?
The POST method isn't a synonym to the create in CRUD. The POST method is used for any operation that isn't standardized, so as long as you document what it does, you're not violating REST, no matter what you do.
There's no such REST principle saying "anything a POST creates should always be accessible via a GET". This is a common misunderstanding due to conflating REST with CRUD. Read this answer for some clarification on that.
In informal language, what a POST says to the server is "take this data and apply it to the resource identified by the given URI, following the rules you documented for the resource media type."
No, you are not violating REST. As long as your interface is uniform it is up to you to determine what actions the urls of your API perform.
As part of your documentation you simply need to state which methods are valid for certain resources and which aren't. I really like to use the Twitter API as a good example of "What to do"
Example: Twitter REST API
POST statuses/update
does not create an object available for access at
GET statuses/update/3
The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is the appropriate response status, depending on whether
or not the response includes an entity that describes the result.
So according to the HTTP standard this is okay.
I am building a game where users can submit answers to questions. I do not want to simply GET the answers for obvious reasons.
What would be a good RESTful URI the check whether the user's answer is the correct one?
So far I am successfully GETting resource data from URIs such as /games, /games/123/levels, and /games/123/levels/easy/345.
Would it still be considered RESTful to have a checkAnswer service located at /games/123/levels/east/345/checkAnswer even though it is a verb instead of a noun?
I know REST is just a concept but I'd like to know peoples' opinions.
Thanks
If you have a route to questions, I would POST an answer to the url /questions/<question_id>/answers and if the answer is good return a status code of 201 - Accepted and if it's incorrect I would return 422 - Unprocessable Entity or maybe a 403 - Forbidden status code depending on what you view as the most fitting status code description.
So in this example the question's ID would be 213 and the body of the POST request could be something like {"answer": "B"}.
I'm trying to use the QBO v3 API object update function described here. The API explorer shows a different uri.
I'm trying to update an account with Id 42. Both of the following URIs get me a 401:
As the documentation would suggest:
https://quickbooks.api.intuit.com/v3/company/0123456789/account?requestid=42
(the above at least gives me a json blob with the 401)
As the api explorer would suggest:
https://qb.sbfinance.intuit.com/v3/company/0123456789/account?operation=update
(here I don't even get the json, just a plain 401)
My request body is successful when I use the api explorer, so I don't believe that's the problem. I also don't believe authentication is the problem, because I can successfully create objects and also make queries with the same headers.
What might I be missing?
Don't put the Account object's ID into the URL. The [?requestid=] from the documentation you mentioned apparently refers to an id related to the request (not the object in question). The API Explorer's URI appears to simply mislead (although I could certainly be missing something here).
In your example, just use this:
https://quickbooks.api.intuit.com/v3/company/0123456789/account
Let the headers and request body do the rest.
Correct BASE URI: https://quickbooks.api.intuit.com/v3/company/
you can refer example request/response section of any entity doc.
Ref -https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/030_entity_services_reference/bill
To debug(401 authentication issue), you can use any standard RestClient.
In the following thread, I've explained how to use RestClinet plugin of Mozilla to test any QBO V3 endpoint.
InvalidTokenException: Unauthorized-401
You can download IPP's devkit and using that devkit you can call any endpoints easily.
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits
Hope it will be useful.
Thanks