I want to check whether my deployed ASP.NET application returns Healthy from health check endpoints or not.
Unfortunately, the success criteria samples of the "Invoke Rest API" release gate only show how to evaluate JSON responses like eq(root['status'], 'successful') or eq(count(jsonpath('Items[?(#.price<50)]')).
As my endpoint doesn't return any JSON I wonder if it's possible to do a simple stupid string equality check somehow?
Of course I could rely on checking the HTTP status code, I feel like it should be possible to access the response body.
This is the exception I get when using eq(root, "Healthy"):
If your endpoint returns just a string try simply this:
eq(root, 'SomeString')
This is really strange that you get such error. It works on my release pipeline:
Here is settings:
And here result:
Agree with Krzysztof Madej
Exception Message: Error parsing API response into a JSON object.
You could check the “URL suffix and parameters” field in “Invoke Rest API task”.
Please make sure that the whole URL is valid.
The whole URL contains the Server URL (Set in service connection) and the URL suffix and parameters (Set in Invoke Rest API task).
Hope this helps.
Related
I'm trying to make get requested with .Q.hg (HTTP get), but I need to edit the request headers to provide API keys. How can I do this?
You can try this function I wrote a few years back for a POC (similar reason - I needed to supply multiple headers). It's based on .Q.hmb which underpins .Q.hp/hg. Please note - it was never extensively tested & there are likely better alternatives out there, but it will perhaps work as a quick solution.
k)req:{[url;method;hd;bd]d:s,s:"\r\n";url:$[10=#url;url;1_$url];p:{$[#y;y;x]}/getenv`$_:\("HTTP";"NO"),\:"_PROXY";u:.Q.hap#url;t:~(~#*p)||/(*":"\:u 2)like/:{(("."=*x)#"*"),x}'","\:p 1;a:$[t;p:.Q.hap#*p;u]1;(4+*r ss d)_r:(`$":",,/($[t;p;u]0 2))($method)," ",$[t;url;u 3]," HTTP/1.1",s,(s/:("Connection: close";"Host: ",u 2),((0<#a)#,$[t;"Proxy-";""],"Authorization: Basic ",.Q.btoa a),($[#hd;(!hd),'": ",/:. hd;()])),($[#bd;(s,"Content-length: ",$#bd),d,bd;d])}
It takes 4 arguments:
Resource URL
HTTP method
Dictionary of headers
Message body as JSON object
Sending a request to a test server..
q).j.k req["https://httpbin.org/get";`GET;("Content-Type";"someOtherHeader")!(.h.ty`json;"blah");""] // no body so pass empty string
args | (`symbol$())!()
headers| `Content-Type`Host`Someotherheader`X-Amzn-Trace-Id!("application/jso..
url | "https://httpbin.org/get"
In our API, one of the endpoint will expect clients to provide body/payload only in certain scenario.
If the API is unable to generate a payload for given request based on the origin of the client then, we want our API to provide response with the right status code to the client, so that they know they have to provide additional information. Once the client fulfills the request with body/payload then the api will process the request as normal.
I just wanted to know is there any standard, predefined status code or procedure to implement this kind of endpoint in API design or do we have to just reject the request with some custom status code and then ask the client to implement a logic based on custom code?.
Thanks,
Vinoth
HTTP Status codes don't, nor are they intended to, map precisely against every real world error. They represent categories of error.
For example, a 404 means that the resource couldn't be found, but if your path is /customers/11/animals/5 then there are several things which could be wrong with the path. customer 11 may not have an animal 5 for example, or there may be no customer 11. There is no http response for "animal not found". Or your API may not have any calls with that pattern of URL to begin with.
You should return a status code which represents what "category" of error you have (in this case, something was not found), and the response body should contain more specific details about the error. To make things simpler, I find it helpful if the data structure is the same for a success and error (it makes parsing much easier) with a "data" field which varies per response.
Here is one example:
status code: 404 not found
body: {
"messageDetailCode" :"CustomerNotFound",
"messageDetail" : "Customer not found",
"data" : null
}
Further reading:
What's an appropriate HTTP status code to return by a REST API service for a validation failure?
I'm trying to get a history report for a repository connection over ManifoldCF REST API. According to the documentation:
https://manifoldcf.apache.org/release/release-2.11/en_US/programmatic-operation.html#History+query+parameters
It should be possible with the following URL (connection name: myConnection):
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection
I have also tried to use some of the history query parameters:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?report=simple
But I am not sure if I am using them correctly or how they should be attached to the URL, because it is not mentioned in the documentation.
The problem is also that I don't receive any error, but an empty object, so it is difficult to debug. The API returns an empty object even for a non-existing connection.
However it works for resources, which doesn't have any attributes, e.g.:
http://localhost:8345/mcf-api-service/json/repositoryconnectionjobs/myConnection
or
http://localhost:8345/mcf-api-service/json/repositoryconnections/myConnection
Thanks in advace for any help.
I also wrote a message to ManifoldCF team and they gave me an answer. So I summed up it for you below.
Query parameters go after the fixed "path" part of the URL and are of the form ?parameter=value¶meter2=value2...
So in the same way as in any other URL.
The problem was that I didn't supply the activity(s) that I wanted to match. Possible activities are e.g. fetch, process. My example:
http://localhost:8345/mcf-api-service/json/repositoryconnectionhistory/myConnection?activity=process&activity=fetch
Finally, the reason why I didn't get an error when I used a connection name that is bogus is because the underlying implementation is merely doing a dumb query and not checking for the legality/existence of the connection name.
I have tried to find a solution in this community in different threads but yet to find one that I am looking for.
I am using SoapUI version 5.3.0 My Application have a couple of RESTful APIs. Initially I am sending json request to a WebService and getting back the following XML Response:
<StartDataExtractResult xmlns="http://schemas.datacontract.org/2004/07/AriaTechCore" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<StatusCode>1</StatusCode>
<StatusText>success</StatusText>
<RequestNumber>397</RequestNumber>
</StartDataExtractResult>
As soon as RequestNumber tag is generated. I have to access to 2 more XML EndPoints (where the value of RequestNumber is appended) to know the Status as below:
A. http://quickextract.quickaudit.in/webs/quickextract.svc/GetExtractionDetails/396
B.
http://quickextract.quickaudit.in/webs/quickextract.svc/GetRequestStatus/396
As of now, I have created the 2 seperateTestSteps for the above mentioned XML Endpoints:
A. http://quickextract.quickaudit.in/webs/quickextract.svc/GetExtractionDetails/
B. http://quickextract.quickaudit.in/webs/quickextract.svc/GetRequestStatus/
Now I need to append the value within tag in the GET Request to get back a response from the WebServices.
Update:
I have created a 'Property Transfer' at Testsuite level as "TSreqNum". This 'Property Transfer' is getting updated as per the initial Response. But I am not sure how would I append "TSreqNum" to construct the complete GET Request as:
http://quickextract.quickaudit.in/webs/quickextract.svc/GetExtractionDetails/TSreqNum
Can anyone help me out please?
You can use the property within the URL of the GET request:
http://host:port/path/${#TestSuite#TSreqNum}
The URL gets updated with the property value.
I have to define an API that answers whether a resource with given ID can be created, like
Can I (caller) create this resource with id=resource1 ?
The possible responses could be
401 - The caller is not authenticated
403 - The caller is authenticated but not authorized to perform this check
200 - Yes, you can create a resource with id=resource1
...
Now my questions are
How can I model the API?
Will, GET /resources/resource1 be a good choice?
What HTTP codes will suite for responses like,
(a) this resource id is already taken, (b) you don't have permission to create this particular id (but only few other ids), (c) you can create this id.
An example in github may help you.
The api designed for checking if a user is following another user:
GET /user/following/:username
The deal information is presented in github's api document
For your question1, I think you can implement like this:
GET /resource/existence/:resource_id
For question2, you may also take a look at github's client errors
Would it be better to just try and create the resource with a POST? and let your implementation handle the response from there? In which case your responses could be:
a) 409: Conflict
b) 401: Unauthorized
c) 200: OK
If that's not possible, then I guess your payload response from a GET can contain the result. Something as simple as:
true: You can create the resource
false: You cannot create the resource
Since you want to check the permissions regarding the addition, you should use a different resource than the one that actually added the element. IMO something like /permissions/{elementName}?id=theid or /permissions/{elementName}/{operationName}?id=theid. Accessing it with method GET would suit.
Using the same resource would be a bit "messy" I think since I would expect the method GET on /resources/resource1 to actually return the content of the element with identifier ressource1.
Regarding the response, I would see this:
401 if the user isn't authentication and the permission resource requires an authentication.
204 if the current user is allowed to add an element with the specified identifier. I don't think that you need a response payload in this case.
Regarding the case when the user isn't allowed to add an element with the provided identifier, I think the status code 403 (Forbidden) suits. Perhaps a status code 400 could also match if you consider that the user provides a wrong content. In this case some hints about the error (identifier value not allowed) should be returned within the response payload.
For me, the status code 409 (Conflict) is more when implementing optimistic locking, i.e. concurrent accesses (updates) on the same element.
Hope it will help you,
Thierry