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.
Related
I write an API for report fetching with detailed filters, such as filters for recordIds, userIds, tagIds, basically multiple different id lists are part of the filter.
So far I coded these fetches as POST requests with id lists in body but I got curious if it is possible to handle these filters as a GET request instead?
What I searched so far yielded that, it doesn't seem possible since there is multiple List based filters and request is likely too big to be a GET but still, I'm curious if there is possible work arounds?
In my opinion, this is according to your requirement.
If you are using post, you could post a complex object inside the body and this request will be more security than the get method.
If you wan to use get method, you could put all the parameter inside the url. Each url will contains the limit and build the complex object in the url is not recommended. If this also match your production environment, you could modify the codes to use get method.
The issue
Can I use actions2 for GET requests with query params?
Example
https://path/filename?id=123&age=45
If this is the url in request, can I access each param as input.id and input.age?
I have not found many resources (basically only one) that show examples of this syntax being used for requests with query string parameters.
The github page redirects to a blog where they talk about the different methods one can apply actions2 syntax to, but does not directly display an example with a GET request
https://www.logisticinfotech.com/2018/sails-js-actions2-example-with-crud/.
The only online source that somewhat confirms this affirmation is the following:
how to get query parameter in action2 in sails.
I am a newbie in SailsJS so feel free to ask me additional information.
Yes, you can use Actions2 for any API request; PUT, POST, GET, etc.
Here is an example from a repo I open sourced: https://github.com/neonexus/sails-react-bootstrap-webpack/blob/release/api/controllers/admin/get-me.js
While the example isn’t using GET params, it would use the “inputs” section just like with a PUT.
A testcase contains 2 requests and 1 groovy script.
Now 1st request is using POST method and 2nd request is using GET method.
Now I am facing an issue that If I am changing the 2nd request as GET, my 1st request also gets turned into GET request while I need 1ST Request to remain as POST.
How to handle this situation?
I am new in Soap UI. any suggestion will be helpful.
You can create multiple methods under the same endpoint - this is what REST is designed to do!
Under your "Api" resource, right-click, and select "New Method". Select this new one to be of type GET. This is going to be your "CheckingResponse". So the final hierarchy for your endpoint will look like:
REST Project 1
+-[REST] http://endpoint.URL/...
+-Api [] <--- THIS IS A RESOURCE
+-[POST] Api <--- THIS IS YOUR CURRENT METHOD
| +-3LevelProducts
+-[GET] Api <--- THIS IS A NEW METHOD
+-CheckingResponse
Refer my answer here:-
http://stackoverflow.com/questions/34786729/if-a-request-is-changed-to-post-then-soapui-changing-all-other-requests-into-po/34831359#34831359
there I have described a full example to achieve the issue
I'm no expert in this so please tell me if I'm way off :)
I'm trying to define a REST service that handles accounts.
/Accounts/32 (GET to fetch one)
/Accounts (GET to fetch all)
And so on...
However, in the sign up process, before an account is created, I would like to verify a couple of fields, like E-mail and ssn, async before the account is created.
How should I go about doing so? I just want to know if they exist in a combination but I shouldn't get a resource back since it's none of my business. :)
Is it valid to do something like this?
/Accounts?ssn=123&email=a#email.com&operation=verifyexistance
Thanks
// Johan
Interesting question, for me I would prefer to do the following:
HEAD /accounts?ssn=123&email=a#email.com
if response status code is 200 then the resource exist on the server
if response status code is 404 then the resource not available and you can continue with registration
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
I like Anas Salman's answer, which suggests the use of HEAD. That's the ideal method.
But I also think that GET is perfectly fine. You are requesting to get information about the resource (the /accounts collection).
GET /accounts?ssn=123&email=a#example.org
When /accounts sees a request in this format (a GET request with an SSN and email address provided), it has enough information to know to respond appropriately with an affirmative or negative.
The addition of an "operation" verb in the query string is the only unRESTFUL part of your example.
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.