Blog

Examine Web Services Testing Tool blog and news updates

Mocking REST services with dynamic responses

Mocking REST services with dynamic responses New in v2.4 version is the ability to send HTTP responses for Mock Resource methods using dynamic response rules that operate on the client request at runtime. By default, resource methods use the static response option. If you would like to customize the response content (entity and metadata) based on certain request details then you can use the ‘dynamic’ option. The main difference between ‘static’ and ‘dynamic’ responses is that when a method is configured to use a ‘static’ response, then the caller is returned the same configured content everytime the resource method is matched. In the case of ‘dynamic’ responses, the response returned to the caller is dependent on the request information. Dynamic Responses are made up of one or more dynamic rules. A rule can contain one or more conditions. Each condition can also in turn contain more conditions (except for NOT which can only contain one child condition). Conditions are evaluated at runtime to either boolean true or false, which determines if the rule succeeds or not. The following are the types of conditions that a rule (and its child condition) can contain: Logical AND Logical OR Logical NOT Request-criteria Condition Rules and conditions are evaluated at runtime when a request arrives at the configured resource method (and its containing resource based on its signature). Conditions can be enabled or disabled during design time and only active conditions are evaluated at runtime. When a rule is successfully evaluated, the response HTTP entity and metadata information for that rule is sent back to the client. The following request criteria that can be...

OAuth 2 Access and Refresh Token Tool

OAuth 2 Access and Refresh Token Tool We are pleased to announce the availability of an easy-to-use and helpful OAuth 2 Access and Refresh Token Tool in v2.3.0 of Examine. The main purpose of this tool is to address one of the biggest challenges of working with REST APIs that require OAuth access tokens, namely obtaining these access tokens from the Authorization servers. The OAuth 2 specification allows for 4 different mechanisms to get the Access Token from the Authorization Server so that the client/consumer can access the resource using this token. The OAuth 2 Token Tool makes it easy to obtain Access Tokens from compliant OAuth 2 service providers (like Google, Twitter (for application-only auth), Salesforce etc). This tool supports all 4 authorization grant types and in this article we’ll give an example of each grant method using a service provider who supports each one. For Authorization Code Grant, Implicit Grant and Resource Owner Password Credentials Grant, we’ll take Salesforce as the provider and for the Client Credentials Grant, we’ll test out Twitter and show you how easy it is (code-less, point-and-click!) to obtain an Access and optionally a Refresh Token. We can also quickly verify that accessing a Resource endpoint using this Access Token works correctly. Pre-requisites: For Salesforce, the first step is to login to your account (developer.force.com) and add a New Connected App under (App Setup -> Create -> Apps) that represents Examine. Specify the Callback URL as https://localhost:8443/OAuthCallback (Note that, most service providers will require that the Authorization Code Grant callback URL be HTTPs based, Examine comes with a Jetty SSL connector enabled on...

Security Token Service configuration to issue SAML 1.1 or 2.0 tokens

Examine Security Token Service configuration to issue SAML 1.1 or 2.0 tokens With v2.1.0, the Examine’s Security Token Service (STS) functionality has been upgraded to issue SAML 1.1 tokens as well, in addition to SAML 2.0 tokens.  The Examine STS feature is based on the JBoss PicketLink project and now includes integration with PicketLink version 2.1.5. Examine provides an easy, quick and code-free GUI approach to setup a functional Security Token Service to issue SAML 1.1/2.0 tokens to clients. With only a few clicks you can setup an STS endpoint to test any SAML-based web service scenarios! This article briefly describes the STS configuration options for Examine and how to setup it up to issue SAML tokens in response to a WS-Trust request (RequestSecurityToken (RST) xml request). The STS endpoint can be enabled or disabled using the ‘Endpoint Status’ switch button (make sure to click on Save to persist the changes and activate/deactivate the endpoint). The following are required fields when setting up the STS STS Name The name of the STS endpoint and is part of the endpoint URL. The STS configuration is unique to each Examine user, so the STS name can be any name even if it is non-unique (i.e. two users select the same name). For e.g. if the STS name is ‘MySTS’ and the endpoint is enabled by the user ‘admin’, then the URL is like this: http://localhost:8080/services/ws/admin/MySTS Keystore The STS requires a valid keystore in JKS/JCEKS/PKCS12 format. This keystore is used to look up the key to sign the issued assertion or encrypt the assertion for a specific service provider (based on the public key...

Mocking REST Web Services made easy

Mocking REST Web Services made easy! With v2.0 of Examine, you now have the capability to create REST resources as part of a REST project that can ably serve the purpose of mocking a REST API. Examine now supports creating a hierarchical resource endpoint structure that closely mimics the JAX-RS way of creating resource classes. This post will describe how you can easily use a code-less GUI-only approach to creating a REST endpoints structure that can be used for mocking purposes. There are often times when working with a REST client or service that you need to standup a hierarchical resource structure for testing purposes. Often you know the endpoint structure and what kind of request and response it should handle. For e.g. you would like the endpoint to be able to handle a specific content type and return a response in another content type. Using JAX-RS you can create a java class and annotate with various annotations like @GET, @Path, @Consumes, @Produces etc to indicate the path structure and the message formats. Each java class is treated as a resource with resources being capable of supporting various HTTP methods through different methods. Similar to this, Examine allows you to create a Mock REST project and then specify the resource structure and details in a tree-like fashion. Each project contains a collection of “root” resources and each root resource in turn contains a collection of “sub-resources”. A resource is nothing but a logical representation of an endpoint that can handle some type of a HTTP request and respond back with a  HTTP response. Each resource can also contain resource...

Examine v2.0.0 released!

New version of Examine (2.0.0) released! Hey! We are happy announce that v2.0.0 of Examine has been released! We have added the ability to create JAX-RS style REST services through a simple and user-friendly UI. You can now create Mock Resources in a tree-like structure and configure the resource request and response parameters. With the jump in the major version, we have updated our evaluation license period to 30 days and also revamped our pricing structure to make it more affordable! For a complete list of Examine features click here. We invite you to download a fully-functional 30 day trial version here. Please contact our Support team if you have any questions related to the product....

Mocking SOAP Services made easy

Mocking SOAP Web Services Starting from v1.1.0, Examine supports mocking SOAP services created from WSDL 1.1 documents. Creating a mock service allows for testing the interfaces associated with a WSDL without requiring an actual implementation to be available and deployed in a web services container. When following a WSDL-first convention of building SOAP services, the WSDL and schema are designed first and then the the various SOAP operations are implemented. As a tester or a client that needs to use this new web service, it is important to be able to verify and use the new SOAP service as quickly as possible. Mocking the SOAP service provides the ability to stand up a valid SOAP endpoint that can be configured to return valid SOAP responses (or specific SOAP faults). Examine comes with a super-easy way to stand up a mock SOAP service endpoint and configure the endpoint to return appropriate SOAP response. Unlike some other tools that support mocking SOAP services, Examine provides a one-click approach deploying the service endpoint. You don’t have to create a WAR file or any other artifact to deploy into a Web Services / HTTP container to make your mock endpoint accessible. Also, to our knowledge Examine is the only tool that allows for configuring the mock SOAP service with WS-Security! This allows for returning signed / encrypted mock responses as well as handling requests with WS-Security. The following are the main steps when it comes to creating a mock SOAP service in Examine: Import a remote or local WSDL file to create a new mock SOAP project (or specify an existing SOAP client...

Reporting Examine bugs / issues

Examine is a relatively new product for testing Web Services. We realize that there could be some bugs or issues that you would encounter in your usage. While we try to do as thorough a job of testing every release we put out, it is possible that we could have missed something! So to make it easy for you to report any bugs you encounter, in addition to the Support website we already have, we have also setup an email alias [bugs@stratumsoft.com] where you can just send an email with the necessary details. This will be automatically submitted as a ticket for our dev team to look at and investigate! So to report a problem, just send an email with the subject line as the summary of the issue and the body containing the issue details (like any exceptions or stack traces). You can also add attachments to the mail (like screenshots or anything useful for debugging) and it would be attached to the issue. You can also copy our support team (support@stratumsoft.com) to ensure someone looks at it immediately too. Hope you enjoy using Examine for developing and testing your web services! Thanks! -The Stratumsoft...

Examine v1.1.0 released!

New version of Examine (1.1.0) released We are pleased to announce that version 1.1.0 of Examine has been released! We have fixed some bugs and added some new features such as: Mock SOAP Services from WSDL 1.1 documents XML Digital Signature Generator XML Digital Signature Validator For a complete list of Examine features click here. We invite you to download a trial version here. If you have any questions please contact our Support team and we’ll get back to you soon!...