I want to use NeoLoad to perform load test on:
1. HTTP traffic
2. REST services
From the NeoLoad site I found that it supports HTTP and SOAP. Can anyone confirm me that using NeoLoad I can perform load testing for REST APIs.
Thank you for your interest in NeoLoad. I'm working at Neotys, the company who publishes it. NeoLoad works at the minimum with HTTP and HTTPS. As REST is just a superset to these, you can load test your API with NeoLoad and this with just the standard license, without any extras.
On top of this, if you are using the JSON format, NeoLoad facilitates the handling of the requests and responses by showing you the XML tree and allowing you to use for instance Xpaths expressions in the content extractors. http://www.neotys.com/documents/doc/neoload/latest/en/html/index.html#862.htm#o867
About SOAP, which brings new operations over HTTP(s), NeoLoad has a module to decode the calls. With NeoLoad, you can load test your webservices based on SOAP
http://www.neotys.com/documents/doc/neoload/latest/en/html/index.html#839.htm
Related
Is SOAP designed to be a stateful? How can it be reached? SOAP use RPC, so where to store data?
Is REST designed to be a stateless? Is it possible to store data in JSON ? Is it so wrong?
Thanks
Is REST designed to be a stateless?
Yes, it really is -- but Fielding is precise about what stateless means in the context of REST:
communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
In other words, to correctly interpret a request, the server does not need to remember any previous requests.
For example, contrast HTTP (where credentials are part of the metadata of the request) with FTP (where credentials are sent separately from the RETR command).
Comparing SOAP with REST is not so suitable, because SOAP is a protocol based on XML and REST is an architectural style that is by definition not bringged to a specific technology.
In any case the common use of REST is via http, like SOAP, and the common usage of REST with json and http is only a comfortable implementation that is very suitable for web development and machine to machine communication due to the incredible good support for json in almost all the modern programming language.
Said that SOAP is definitely stateless!.
When we fire a web service call with soap we create a SOAP envelop in xml and send it on a http channel, that is stateless by default.
During the years near to SOAP many other protocols that can be used with SOAP can add some feature to the protocol the well known WS-*. BPEL deserves some discussion, it is the most important standard for SOAP orchestration.
Even if with BPEL in my experience the engine provide a SOAP web service in order to create a "state full" web service, the fact that a BPEL process is exposed via SOAP it is not correlated with SOAP. BPEL is BPEL and SOAP is SOAP are two separated things.
said that yes REST is an architectural style that is stateless by design and it is particular suitable and used with http, but even soap is a stateless protocol that use http like transportation layer.
for the storing data part of the question, storing data is a application concern. Of course you can pass data in a rest api like a SOAP web service. For the SOAP web service usually you will post data on the body of the SOAP envelop. In a REST service typically you are creating/updating a resource and for this reason using the classical http implementation of REST you will perform a POST(create)/PUT(update all the resource)/
PATCH(update only a piece of resource) pasing the data in the body of the http request. of course do not forget the Content-Type http header on application/json.
I hope that it can help you
I read some articles and i search many about differences between Rest WCF vs Web api but I just find difference between WCF vs Web api , I find some difference:
WCF Rest=>
a)It support HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
b)To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
c)Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
d)It support XML, JSON and ATOM data format.
and
WebApi=> a)Unlike WCF Rest service, it use the full featues of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
b)Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
I want know other differences between them, and when is it better to use WebApi and when Rest Wcf?
I would say, if you start a new project and you need to expose a REST web interface in .NET, Web API is the way to go because AFAIK, WCF is deprecated. I would only consider to use WCF Rest if you have to expose both, SOAP and REST web interfaces.
WCF is not the good choice for REST because it was not made for it, when they implemented it they did lots of bad hacks. you can see how they try to convert xml to josn here
WCF is NOT deprecated, so powerful, and no framework can be comparable to it yet. but it is not for REST.
We are trying to perform tests using Rest Assured Api but we aren't getting success with the response. We sent a request but the response is a faultcode (xml). The same request was made successfully using Soapui.
So, we searched a lot, people say that rest assured supports SOAP and others says that doesn't support.
Anyone knows what is the truth? Supports or not?
While it does not specifically support SOAP protocol, nothing stops you from using RestAssured for SOAP Servers testing - because it is just sending and receiving XML over HTTP and RestAssured does this perfectly well.
To be honest, the fact that RestAssured is not specifically designed to support SOAP makes it even more valuable for error testing, which would be really difficult with SOAP-centered clients.
Here's more details how one can verify XML content: https://github.com/rest-assured/rest-assured/wiki/Usage#example-2---xml
Rest-Assured framework only supports testing REST services.
You can read the introductory post by Johan (Rest-Assured committer) in the below link:
https://www.jayway.com/2013/11/29/rest-assured-2-0-testing-your-rest-services-is-easier-than-ever/
Also in the source code of REST-Assured in Github, it is never mentioned about supporting SOAP services, or has code that supports it.
https://github.com/rest-assured/rest-assured
If you want a single framework supporting both REST and SOAP services try the following options.
http://www.citrusframework.org/
https://www.soapui.org/developers-corner/integrating-with-soapui.html
Currently, We are leveraging a REST API framework tool to automate large soap msgs for api testing, fundamentally rest and soap are same.
The only difference is SOAP msg payload is in xml and response is in xml, will have single header and single type of https request -POST.
you just have to write supporting utils for constructing payload and then processing response.
I'm looking for best way to automate generation of REST ws.
We have collection of web services (SOAP) with WSDLs generated for them. I was required to provide different APIs to invoke these web services. (PHP, Pyton, REST, CLI ...)
One of requirement is to have REST API for these ws.
What is the best way to generate REST client/server, is there any automatic tools for that?
There is a chance that WSDLs will change each release.
Thanks
It's not possible to generate REST API from WSDL. You can't mix oranges and apples
SOAP is a protocol build on top of HTTP. A WebService is represented by a set of methods/actions. You can see a WebService as sophisticated RPC. Generally we can say that WebServices are about verbs, to call remote methods/actions. A WebService also doesn't have uniform interface and that's the reason why WSDL exists.
REST is architectural style (scope is broader than just API). REST API is represented by a set of resources and representations. A resource is source of an information and is managed via uniform interface. Generally we can say that REST API is about nouns. Because all resources must have uniform interface there is no need for WADL (an unsuccessful attempt to create something like WSDL for REST).
I doubt you can automatically transform verbs into nouns, etc.
Please check the below article that describes how to use WSDL2.0 to describe REST Services. It can only be used if the intended message format is XML.
https://www.ibm.com/developerworks/library/ws-restwsdl/
Instead of rewriting an existing SOAP-based web service, use API Express to present it as a mobile-ready REST service. No conversion necessary. Continue to run the SOAP service and, with a WSDL file and a few configuration parameters, it can easily be integrated into mobile apps as a REST service.
How to Expose a WSDL Service (SOAP) as REST API: https://dzone.com/articles/how-to-expose-a-wsdl-service-soap-as-rest-api
Appery.io API Express: https://appery.io/api-express/
I am working with a CRM System that provides two types of APIs: servlet API & REST API, both of which are over HTTP.
I used to integrate with REST API from my ASP.NET MVC web application by calling the REST URL and manipulating the returned JSON or XML. But I cannot figure out what is meant by a servlet API and can these APIs be called over the web from my ASP.NET MVC application or these APIs should be called inside a Java application?
Sorry if my question seems trivial to someone.
The Java Servlet API refers to a set of classes used to implement server side programs. The main player is the Servlet:
A servlet is a small Java program that runs within a Web server. Servlets receive and respond to requests from Web clients, usually across HTTP, the HyperText Transfer Protocol.
If you want a very simplistic analogy, the Servlet is Java's version of CGI (Common Gateway Interface).
A REST API is a way to build applications by fully using the architecture of the web. Leaving all details of REST aside and grossly simplifying, it's basically a HTTP API.
If you want to build a HTTP API, you can use Servlets. So you can also use servlets to build a REST API although there are better alternatives to that (e.g. JAX-RS) because servlets are a "low level" component and nothing shields you from all the boiler plate code you need to write.
You can of course call a Java application build on top of the Servlet API from other clients (e.g. from ASP.NET MVC). That's what it was built for. For this reason I don't really understand what exactly your CRM system means by a Servlet API and (a separate!?) REST API... so maybe ask the CRM provider?
EDIT : Based on what I've read about the ManageEngine Service deskPlus APIs, I'm thinking that this is just an unfortunate name chosen by the provider.
As I mentioned in my comments, when you say REST API you already provide some information from the beginning. Most people, when told about REST understand that you have some abstract resources, that these resources can have multiple representations (JSON, XML, whatever), that each resource is identified by a URI, that /customers is referring to a list of customers resources, that /customers/1 is a customer and that /customers/2 is another one, that you use GET /customers/1 to find out details about the customer and DELETE /customers/1 to delete it etc.
REST is one way to interact with an application, another one is to expose operations that can be called by clients, for example like what SOAP is doing. Before REST became the new kid in town people were doing stuff with SOAP. Unlike accessing resources, SOAP is focused on accessing operations. When you mention SOAP to someone she knows that it's a protocol that can use HTTP's POST to transmit messages around, that each message has an XML payload that contains the operation name to invoke and the parameters needed for the call etc.
But even before SOAP and REST becoming widely known, people realized that they can use a form submit to sneak in RPC calls through HTTP. The HTTP form based submission is one of the methods of the API in ManageEngine Service deskPlus. But the form based submission method (as far as I know) doesn't have a cool name like SOAP or REST... so maybe that's why it was named after the Servlet API?! (I'm once again emphasizing that this is just the server implementation which is not important in the context of the HTTP protocol).
So to conclude: Yes, you CAN call the ManageEngine Service deskPlus Servlet API from ASP.NET, even a web browser or any kind of HTTP capable client.