I have a Jersey 2.x application running in tomcat. All the method implementations are working as expected, and even I am able to get WADL by navigating to http://{host}:{port}/JerseyRESTWebapp/ws/rest/application.wadl.
Everything is great so far.
Now, Out of curiosity I tried navigating to http://{host}:{port}/JerseyRESTWebapp/ws/rest/employees URL using using HTTP OPTIONS method expecting i will get 405 Method not allowed but i got the 200 OK and response body contains the WADL. Can someone let me know why is this happening? I am using POSTMAN chrome extension as REST client.
Also in the Response Allow Header, i am getting POST,GET,DELETE,OPTIONS,HEAD. I am missing PUT method here. why?
This is how the resource discovery works by default. It's implemented to follow the spec in regards to OPTIONS resource discovery
This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
If you want to disable the WADL, you can by setting the property ServerProperties.WADL_FEATURE_DISABLE to true.
If you're curious about how this is implemented, check out the source for the WadlModelProcessor. It goes through all the resource models and adds an extra OPTIONS resource method. You can read more about the ModelProcessor in the Jersey docs Programmatic API for Building Resources
My org is trying to use JMeter as part of a test automation suite to test some back end REST APIs. Currently one of them supports using JSON queries as a way to get filtered results back from a GET request.
We are using the JMeter UI to create these tests and since all the other API calls work under the HttpClient3.1 HTTP Request implementation that is the implementation that I am currently using to get this to work. With this implementation I get the following when looking at the failure in the results tree (response data portion) I have made the error slightly more generic to protect some IP:
java.lang.IllegalArgumentException: Invalid uri 'https://server:port/restservice/v1/users?firstname_query={"in":["User1FirstName","User2FirstName"]}': Invalid query
at org.apache.commons.httpclient.HttpMethodBase.(HttpMethodBase.java:222)
at org.apache.commons.httpclient.methods.GetMethod.(GetMethod.java:89)
at org.apache.jmeter.protocol.http.sampler.HTTPHC3Impl.sample(HTTPHC3Impl.java:229)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1146)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1135)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261)
at java.lang.Thread.run(Unknown Source)
I have also tried the same request using the Java implementation and get a similar result.
If anyone has any ideas or if you need more information let me know and thank you again in advance for any help you may be able to provide.
Your HTTP Request configuration is a little bit incorrect. JSON entities contain braces {} which are not allowed in URLs so you need to encode them.
Configure your HTTP Request sampler like:
Make sure "Encode" box is ticked.
And this way you will be able to send JSON with HTTP GET Requests. You can use View Results Tree listener to inspect request and response details:
You might also need to add HTTP Header Manager to your Test Plan and configure it to send Content-Type header with the value of application/json. See Testing SOAP/REST Web Services Using JMeter article for more details on properly configuring JMeter for testing REST APIs.
The REST URL mapping for Spring Boot when using JHipster is properly according to best REST practices, for example, the following url scheme is employed for GET, PUT, POST & DELETE methods:
api/appointments/{0}
But in the Account resource that comes with every project that uses JHipster generator, the URL scheme is as follows:
api/register
api/activate
api/authenticate
api/account
api/account/change_password
I will like to understand the reason behind this mapping, because it could have been just one URL, like
api/account
and we could provide query parameters in POST and/or PUT methods. But there must be a best practice behind it, though I am not able to completely understand it. Any elaboration on the topic will be great.
I am working on a SoapUI automation project for Restful service.I'm new to SoapUi and Restful services itself.
I have the Rest API generated in SoapUI. I don't have any sample requests given by the developer so I am working on creating the requests myself. I only have a JSON contract document to refer to which was created for the UI developers. Now according to the specification documents, some get methods in the API's are supposed to have two parameters "token" and "ContextName". However, when I imported the WADL file in SoapUI, the request body only has the "token" parameter. So am I manually supposed to add the other missing parameter in my requests? and is it possible to create a POST(rest test request) in a GET resource?
I don't think you can have multiple body parameters (or if you can, it's certainly not a good practice!). Check to see if the ContextName parameter is a different type of parameter such as a query or path parameter (called template parameter in SoapUI). Here is some info about different types of REST parameters in SoapUI: http://www.soapui.org/rest-testing/understanding-rest-parameters.html
I'm not sure what you mean in your second question. Perhaps you want to write a Test Case with multiple Test Steps (a GET and a POST)? Check out this link: http://www.soapui.org/functional-testing/structuring-and-running-tests.html Also look at the other sections under Functional Testing to learn how to control the flow of test steps.
I don't make this very general question post lightly, but I've maxed out what I can figure out on my own.
I'm starting up the QA Test Automation at my new company (they don't automate anything currently) and they've elected to use SoapUI for this procedure.
The application they're developing is a REST application (I don't really have any idea what that means) so I'm trying to build a REST request and Test Suite to reach our internal test server (which gets me XML that I am not allowed to post here - but it does reach the server successfully!) and then try to do a Login/Logout test.
I'm asking for help with methodology, because I have no idea where to start. I;ve Googled and trolled their support forums and looked in every corner of YouTube. Everyone is doing something different enough that I can't relate or use it.
Does anybody out there use SoapUI and test functional login in a REST application? I can write HTML/CSS and I'm pretty Java savvy, so I can do technical stuff if I know what to look for and what to learn.
Feeling overwhelmed. This was not in my job description when I started.
You should start with REST, and after that with SoapUI.
It is hard to catch the essence of REST.
It is like the hybrid of SOAP and a simple HTML driven web application. By SOAP you describe your web service with a WSDL. By a web application you send back hypermedia, so you don't have to write a WSDL or any descriptor to your application. This is convention over configuration...
REST uses the same approach, so it sends back hypermedia as well, but it sends not HTML, because it is not machine processable. The hypermedia sent by a REST API is usually an XML or a JSON derivative, for example ATOM+XML, JSON-LD, etc... If your web service does not send back hyperlinks, then it is not a real REST service just a SOAP web service with some REST constraints. There is a big difference. By SOAP you have to know everything about the operation name and the parameters if you want to send a request. If something changes, then your SOAP client breaks immediately. By REST your automated client follows links, checks their link-relation, or the bound linked data and recognizes which link is what it was looking for. So the modification of the link's url is irrelevant in the client, because it follows the vocabulary of the application, for example: hydra is a project which tries to describe these application level semantics in a general way, and tries to bind it to open linked data.
So at first you have to check that you have a real REST API, which follows the HATEOAS principle, or just a REST like SOAP web service. This is very important if you want to write end to end tests against it. By testing REST, you have to follow the links in your tests returned by the web API. By testing REST like SOAP, you have to build the links yourself in your tests... How to build such a link? I am sure you got a description of your REST API, but a link looks usually something like this in a JSON format:
{
rel: "link-relations",
method: "METHOD",
href: "domain/api-root/version/resource-path?map-reduce",
data: {...},
title: "...",
...
}
Ofc. there is some difference by every hypermedia, so you have to check your XML hypermedia type, how it represents links... The link-relations and maybe other attributes bind your data to the semantics of your REST API. The METHOD is always a verb, usually: GET, POST, PUT, PATCH, DELETE, maybe OPTIONS, and so on... There are only a few REST verbs, each of them has a specific meaning. In the url: The domain is the domain name of your application, e.g. https://example.com. The api-root is the root of your REST API, usually /api. The version is the version number of the currently used API, usually /v1. Only non backward compatible vocabulary changes should affect this version number. The resource-path is the path of your resource, usually /users or /users/inf3rno, etc... By REST you have resources. Each of them has a unique resource-path, and as you can see, every word in that path is a noun. So resources are something you can modify or display with a verb. For example a GET /users/inf3rno should return a representation of my profile page, and a PATCH /users/inf3rno {nick: "Leslie"} will turn my nick name: inf3rno into Leslie. By REST every resource should have only a single resource-path, so this is always a unique identifier, therefore the previous example with PATCH was not so perfect if you want to have multiple users with the same nick... The map-reduce in the queryString of the url, and it contains the sorting, pagination and filtering settings of the resource you want to modify or display. For example you can retrieve some data of every user with a first name: "Leslie" with GET /users?filters="firstName: 'Leslie'"&page=3&count=25. There is a difference between the following url-s: /users?id="inf3rno" and /users/inf3rno. The first one points to a collection resource and filters the result by its representation, the second one points to a single item resource. So a GET should return a collection representation with a single item by the first one, and an item representation by the seconds one. By the resource modifying methods there is no difference between the 2 urls... So it is recommended to add only a unique identifier to the resource-path if you want to select an item resource from a collection. By reducing the collection representation in any other ways, you have to add the filters to the queryString. The data part contains the params from the input fields. The title is the title of the link, and so on... You can use url-templates of you want to put input params to the url as well...
By REST the client maintains the session, and it sends the credentials (username, password) with every request. This is because the REST service is like John Snow, it does not know anything about the session or the identity of the user. It has to authenticate every request. To do that it uses a credentials -> permissions cache. This is a good approach, because the service scales very well if it does not have to maintain the session, which is part of the application state (the state of the client)... The REST service maintains only the resource state, which is not dependent on the clients...
The response to your REST requests is usually a hypermedia which contains the links you can follow and the data you requested. By REST like SOAP web services you get only the data in a JSON or XML format. Every response should contain a proper status header. The most frequent status codes are:
200 - ok (by successful PUT, PATCH and GET)
201 - created (by successful POST)
202 - accepted (by async request with eventual consistency)
204 - no content (by successful DELETE)
206 - partial content (by pagination with range headers)
301 - moved permanently (by migration)
304 - not modified (by cache)
400 - bad request (by invalid input)
401 - unauthorized (if no password given, or wrong username or password)
403 - access denied (if your account does not have permission to perform the task)
404 - not found (by unknown resource)
409 - conflict (by concurrency issues or duplicated request or db constraint problems)
410 - gone (if the resource was present before, but it is already deleted)
415 - unsupported media type (if the client wants the response in an unknown media type)
500 - internal server error (if the request was okay, but something went wrong by processing it)
By any error you have to send a detailed error message with a custom error code, which is understandable for the users, not just the developers...
That's how a REST API looks like.
To test it with e2e tests you have to set fixtures send REST requests and check their response. So it is like any other test... The SoapUI is not necessarily the best tool to do that, I read many complaints about it... I personally never used it, but it is not so hard to write your custom testing system. You need a testing framework, which can compare expected and actual values. You need something to send HTTP requests, or simply mock out the HTTP framework of the REST API. You need something for the fixture. By integration tests you can mock out the business logic and the HTTP framework as well, so by those you just inject the mock dependencies and check the calls. By e2e tests you need a test data set, and compare it with the result XML in your case... If you want to e2e test your client, you can use selenium if it is HTML based, maybe with nightwatch.js. By testing a real REST API, you'll need an automated browser, like selenium for your REST API implementation, which can select and follow the proper links. If you are developing the REST API you would write a browser like that anyways if you want an example client for your 3rd party client developers.