If a request is changed to POST, then SoapUI changing all other requests into POST method - rest

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

Related

Acumatica - Generic Inquiry via REST

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.

Rest API GET method restriction

I wanted to clarify on a usecase where i struggled to use GET method for a fetch operation.
I was asked to build a API to generate message from a predefined template. In the request i receive template-ID and the dynamic content which needs to be substituted. Dynamic content vary based on the template-ID.
I have designed like
Method = POST
URL pattern = /messagegenerator/v1/templateID
Body = Dynamic Content in the form of JSON
Response = Plain text message
Problem i faced: When i use GET method then template content should be passed in the URL which has length restriction. We wanted to prepare email message which has more dynamic content.
Ultimately this service won't create any resource but still i forced to use POST method.
Am i missing something?
Rest standard missing?
Is there any better way of doing this?
Is there any restrictions on the length of get URL parameters?
Although there is no url limit in the standard, there is this old advice about keeping your urls under 2000 characters: What is the maximum length of a URL in different browsers?
To the point: in your case sending a POST request with all data in the body is the best solution. Putting email body fragments, or anything that huge (if I understand correctly) into a url is very ugly :). Even if the request does not change anything on the server technically, you should use POST, yes.
You need to create a new API which supports http get method, because one API can't receive more than on http method.
As you pointed out, in REST the POST method is thought of creating a new resource. In your case a new resource "message" is generated indeed by posting the content even if you do not keep it on the server.
But you are using POST on a template! This should create a new template. To resolve this, add a subresource to the template resource so you can express that it is a message that is created.
I would even extend the URL by adding a "template" after the "v1" to make more explicit that it is the "template" resouce on the first level.
The only change necessary for that would be to modify the URL like this:
URL pattern = /messagegenerator/v1/template/<templateID>/message
So you could have (even if you do not implement it now):
GET on /messagegenerator/v1/template/ -> Deliver a list of templates
POST on /messagegenerator/v1/template/ -> Create a new template
DELETE on /messagegenerator/v1/template/<templateID> -> Remove a template
PUT on /messagegenerator/v1/template/<templateID> -> Modify a template
GET on /messagegenerator/v1/template/<templateID>/message -> Deliver a list of messages
POST on /messagegenerator/v1/template/<templateID>/message -> Create a new message
DELETE on /messagegenerator/v1/template/<templateID>/message/<messageID> -> Remove a message
PUT on /messagegenerator/v1/template/<templateID>/message/<messageID> -> Modify a message
So you could even manage and return old messages if you saved and assigned them an ID!

Cannot access previous response in repository with DHC

I use DHC by Reslet a Chrome extension, version 1.2.
When I create a first POST request to create an entity
If I want to access to this request in a another request (repository feature) I cannot access the response.
I have the same problem with DELETE requests, but not for GET requests
I'm not sure to correctly understand what you want to do but I'll try to give you an answer.
Imagine I want to execute the following:
POST request to add a company using the URL /companies and get its identifier from the response
GET request to get the newly created company using the identifier from the previous request
To do that I need to save the first request. I save it with the name 1 - Add company under the project Company project and the service CRUD service:
Company project
CRUD service
1 - Add company
Here is what I can use within the second request within its URL field:
contactsapi.apispark.net/v1/companies/{"Company project"
."CRUD scenario"."1 - Add company".response.body.id}
This way DHC will use the value of the id field in the response body from the latest executed 1 - Add company request in the history.

PHPStorm 8.0.3 Rest client not appending request parameters in POST request

Like the title says I think I have a problem with the "Test RESTful web service" client. When I make a GET request, the request parameters, for example ?test=1&b=2 would be added. When I make a POST request, they are not added anymore.
Is this normal behaviour, or a bug in the client? And is allowing the request parameters when using a POST method a good practice?
Known issue, please vote for WEB-10584

How to pass extra parameters in HTTP DELETE request?

I am writing a REST API, which supports POST/GET/DELETE method for the same url.
For the DELETE method, the API needs extra parameters (details of the deletion). But the library I am using doesn't support request body for DELETE method, how can I do it?
If I put the parameter in URL like:
DELETE /API/Resource/id/parameter
Then I break the RESTyness.
Or I need to use another method POST/PUT, which is not RESTy, either.
Why is POST / PUT not RESTy? Take a look at the twitter REST API: You can destroy a status by POSTing to /statuses/id/destroy. That request does accept parameters. You could do something similar to this:
POST /API/Resource/id/destroy
I think that is RESTy enough.