I am using Postman mock server to create a mock endpoint where I need the response of the request to contain the request parameter as well as few other key values.
For example if my endpoint is /test?id=123 then i need the response as
{
"id":"123",
"name":"anyRandomName"
}
Similarly, when I hit /test?id=234 then the response should be
{
"id":"234",
"name":"anyRandomName2"
}
One way to achieve this is by making 2 endpoints with specific query parameters, in this example /test?id=123 and /test?id=234.
But i am looking for a way where i can read the request parameter just like {{$id}} or something like this. Postman do provide keywords like {{$randomAlphaNumeric}} which returns random strings but this will change in every hit.
You can pass the example name in headers while making a call to the mock API with key "x-mock-response-name". this will return the example set with that name.
Related
GET http://localhost/foo/api/v1/bars/:id
How to have different JSON responses registered for a GET call. We would like the GET call to return a separate response based on whether a CLI is invoking or the user interface is calling the API by passing a query parameter. But how do we register different serializers dynamically on the response.
You can use a User-Agent request header to identify the application doing the request. There are good tutorials to check how to access the headers in Spring, like this Baeldung one.
I'm new to Java programming and I have the following snippet on which I want to write unit test:
Response response = request.get();
if (response.getStatusInfo().getFamily().equals(Response.Status.Family.SUCCESSFUL)) {
return response.readEntity(type);
}
I'm able to create the scenario where HTTP request returns a valid response using the below code:
stubFor(get("someUrl").willReturn(aResponse().withStatus(200)));
I want to create another scenario where the method call response.readEntity(type) throws an exception. For this, I require that request.get() method returns me a mocked object so that I can define the desired behavior on the mocked object.
I read the documentation provided at http://wiremock.org/docs to find how to do this behavior but didn't find any way to return a mocked object as HTTP response.
Also, the request variable is not injected and hence I can't mock it directly.
You cannot do something like
stubFor(get("/$metadata?annotations=true").willReturn(aResponse().withStatus(200).withBody(Mock()));. It is because wiremock acts only as http server mock. Only thing you can configure is response (ex. in JSON).
What you can do is to return for example 400 and error code body from wiremock and check if you code accepts this message and act on it correctly.
I'm facing a particular use case while using Wiremock standalone API.
I would like to be able to reuse a response body generated by stubbing for a another request (stubbed as well) as a context model. The purpose is to store for a generated Id the entire response data, that would allow me to serve it again simply knowing the Id, in a get method particularly (where there is no request body).
Is there a way while defining a stub of response to capture the generated response, in order to store it?
Or if you have other better idea.
Finally I solved the problem by using an okhttp interceptor (which depends on your client solution).
In the interceptor, I store every response data (e.g.: a generated ID) and set them in every next request headers when it matches with part of the the response stored.
adding them to the request headers allows me to access them in a json template file for instance
If I have a #Controller method whose parameter is a #RequestBody param, I usually have to write some jQuery script or something similar to perform an AJAX request with JSON object in order to call that method. If I tried calling that method via a web browser directly, it returns with a Error 415 Unsupported Media Type.
Is there any alternative to just quickly call such method using browser without having to write some jQuery code? Like perhaps a way to write the JSON object in the URL/address bar?
code:
#RequestMapping("testCall")
#ResponseBody
public List<TestObject> getTestCall (#RequestBody TestParams testParams) {
return stuff;
}
public class TestParams {
private Integer testNumber;
//getter/setter for testNumber
}
I thought maybe I could just do:
http://localhost/testCall?testNumber=1
maybe Spring would auto populate a new TestParams instance with that property set to 1 but that didnt work...
maybe I need to do something extra for that?
The whole point of a #RequestBody annotated parameters is for the Spring MVC stack to use the HTTP request body to produce an argument that will be bound to the parameter. As such, you need to provide a request body. Sending a request body is very atypical for a GET request. As such, browsers don't typically support it, at least not when simply entering an address in the address bar and submitting the request.
You'll need to use a different HTTP client, like jQuery. I typically have a small Java project in Eclipse that's setup with an Apache HTTP components client which can send HTTP requests to whatever server. It takes a few seconds/minutes to setup the correct request body and run.
I have spent the last year building a REST API, and by far the best way to exercise that API manually is using the Chrome Extension, Postman. I cannot recommend this tool enough.
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en
To test your simple example you'll need to invoke a POST (I assume that as you have a request body, but your controller method doesn't define a HTTP Verb) using POSTMAN to your Url (like the following example):
POST /contextRoot/testCall
{
"testNumber": 1
}
If you want to test your API automatically (which I recommend), you can use the excellent Spring Mvc Test project. This allows your to call your API via a rest-like DSL and assert that the response is in the shape you want. More details can be found here:
http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/testing.html#spring-mvc-test-framework
you can add request params to the getTestCall method:
#RequestParam(value = "testNumber", required = false, defaultValue = "") String testNumber
There is a chrome app called Advanced REST client. You can pass the data in form of json to your controller using this chrome app. For eg. json data is
id:1,
name:"xyz"
whereas the controller can have #RequestBody Person form.
The Person class would be a POJO having id and name as instance variables. The Spring would automatically map the json data to the form.
I think this is the easiest and simplest way of checking your spring controller.
Check the extension Advanced REST client here
From what I know You can send JSON object to the webbrowser and it will be displayed without further need of AJAX.
useful tutorial:
http://www.mkyong.com/spring-mvc/spring-3-mvc-and-json-example/
I have to invoke a restful Web-Service from client side java class.
I need to pass HashMap, Strings and it must return me a list of beans.
I am using jersey restful web service
My REST service is like this:
#put
public List<MilestoneDetailsBean> getMPPReader(
#QueryParam("username") String username,
#QueryParam("projid") String projid,
#QueryParam("mppfile") File file,
#QueryParam("dbtemplate") Map<String,Integer> dbtemplate)
could some one help me with how could I:
assign values to these query parameters in my client side java code
what type of produces and consumes parameter I should put for my Web-Service
1) depends on how you create the query. QueryParams are those parts of an URL behind the ?: ?key=value&key2=value2
So what you could do is to just append the keys and values to the request URL. Remember to encode the values.
Like: http://mydomain/service?username=hage&projid=hello+world&mppfile=myfile.txt
Map is not usable for this. See here
2) Dont't know. Produces definitely depends on how you want to return the data (as xml, json, etc) and Consumes depends on what data you want to send to the server
Generally, for the client there exists a Jersey client API. Didn't use it yet, but you might look at it.