I am getting started on an API testing project using supertest, mocha and chai. I am using postman to manually send the requests first to ensure they are working before writing the code for them.
All my get and post commands are working successfully except for this patch request. This is the first patch request I am attempting to send.
Request Headers
Request Body
Code
First request is passing, second is failing
The URL's are identical so I know they are valid and the authorization is working correctly.
I feel that as the first command is passing this is not a sync issue
This definitely needs to be a patch request according to the swagger
I'm new to API testing so would greatly appreciate any insight anyone may have into this issue.
Well nobody ever likes to hear it but it appears my problem has resolved itself after leaving it for a day.
I really wish I had an understanding of why this has happened but for now it appears I will have to go ahead unsure of what caused it or how it was resolved.
Related
We're currently testing a Microsoft Graph API integration that works with the Calendar created in Bookings. We aren't running off the Bookings API as it is still in preview and lacks certain data points, but rather interfacing directly with the underlying calendar as it works and syncs properly with Bookings, as long as you stick to basic operation such as GETS and DELETES.
We ran into an odd scenario in which the Graph API returns a 204 NO CONTENT status on a failing DELETE request. The user being tested has REVIEWER folder permissions on the calendar. When a DELETE request goes out, the event does not delete (as intended with someone who only had REVIEWER permissions), however the response received is a 204 NO CONTENT response, which should only be returning upon a successful request according to the Graph API Documentation.
Sample:
//Signed in user is listed a REVIEWER on calendar
REQUEST: DELETE https://graph.microsoft.com/v1.0/users/{id}/events/{id}
RESPONSE: 204 NO CONTENT //Even though calendar event remains
Is this an issue with the Graph API or do I need to get permissions issues for failed requests another way? Seems wrong it would show successful for a failed request, but I know things may get weird working with the underlying calendar.
Try to clear the cache and cookies, and then re-execute the request.
I think there is something wrong with your request URL, please change to:
https://graph.microsoft.com/v1.0/users/{user_id}/calendar/events/{id}
or
https://graph.microsoft.com/v1.0/users/{user_id}/calendars/{id}/events/{id}
After my test, it can work well for me.
What is the difference between the way a browser calls the URL and doing it via Rest Debugger or HTTP Components?
I have a 3rd party Web REST API that work every time in a browser (IE it returns JSON as expected), but when I use (GET) the same URL in the Delphi REST Debugger it returns error code 429 Too Many Requests.
I am not allowed to post the exact URL here (I'm sorry, boss has the last say but it is like this https://xxxx.yyyy.com.au/search/resources/store/zzzzz/productview/123456).
For additional information the result is consistent giving the 429 error when I use NetHTTPClient and NetHTTPRequest components as well as using the Delphi REST Components.
I thought that setting the user agent to be the same as my browsers might help, but alas it didn't. I use Delphi 10.3.3 Rio
I'm a bit new to REST and haven't found an answer by googling for a couple of days now. Any help will be most appreciated.
Thanks,
John
The answer is cookies. When I rejected all cookies I could see the behavior as stated by #RemyLebeau where the page is in a continuous loop. The browser sends a cookie with the request header. I'm new to all of this, so I'll try to replicate what the browser is doing and see what happens. If I get really stuck I'll post another question specifically about cookies. Many thanks to all who offered advice. Most appreciated. I put this here because someone deleted this as an answer.
We are trying to set up an api interface between two web-applications. When testing the GET call, it works from PostMan while not working from soapUI. The web-apps seems to be failing like soapUI.
I am hoping that if we can identify and understand the difference, we can resolve the issue.
Some info:
Both use Basic Authentication with a username and password (they both seem to be allowed access, as authenticated POST calls work from both testing tools).
From neither of the tools do we pass any parameter explicitly. It's a static URL we are calling to. However, the URL does include a resource-id (a target report) that could be set up as a template parameter if we wanted to.
When making the call from soapUI, the log on the application that is supposed to respond to the GET says javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"reportExecution").
The call we use is something like GET [endpoint]/jasperserver-pro/rest_v2/reportExecutions/0cc3aefc-29b6-45b1-8248-ae4e1457bb87/status
Update: By now I am quite sure this has to do with cookies. The request id 0cc3aefc-29b6-45b1-8248-ae4e1457bb87 above was received in a previous call and you need to to request the status with the same access token, which you can do with Cookies, but setting that up in soapUI is no simple matter (at least not for me). In PostMan this seems to be the standard behaviour, and hence the difference in result.
Best regards
Pieka
I'm attempting to use SoapUI (5.0.0 beta) to test a RESTful web service which issues asynchronous responses to a supplied Callback URL.
So far, I am able to invoke the service and confirm the initial synchronous response received. I have also created a 'REST MockService' that issues an appropriate response to the callback received from the server, and I supply the endpoint for this as the Callback URL in the initial request.
What I am now struggling with is creating a test case that ties the two together such that I can 'expect' the asynchronous callback before proceeding to another step in my test case. I tried adding a 'Mock Response' Test Step to my test case following the initial request. However, this just yields an unhelpful 'Missing SOAP Operations to Mock in Project' error message. I took a brief look at the SoapUI source for this error message and discovered the method returning the error is first checking if I am using a WSDL interface. Why I would be doing so with a REST project is beyond me, but there you have it!
Appreciate any guidance on how to proceed!
Having logged a query on the SoapUI Community Board, it seems there is currently not a good mechanism for achieving this, but my query has prompted an enhancement request at least!
http://forum.soapui.org/viewtopic.php?f=5&t=23697
Currently, we are using GetHttpRequestData().headers to get real IP address of User. However, we are facing following issue. when we try to call SOAP web service request, we receive following error Premature end of file. I already searched the web and found out that there is bug in ColdFusion 8.0.
I don't know if this bug is resolved yet.
Is there any alternate solution?
Please help me.
thanks
Is the SOAP request coming in to ColdFusion from a client and that is where you are getting the error or is a user hitting a coldfusion page that is then making a soap request to some other service and that is generating the error?
We had the exact same issue. I don't know if you've found a solution yet but the workaround I found is using getPageContext().getRequest().getHeader("name of header here") to retrieve the request header I'm looking for. This doesn't break to SOAP calls like getHttpRequestData.