Web Service Basistest

Gepostet von in Programmierung, Web Service am 1 Oktober, 2012 | Keine Kommentare

Web Service BasistestDie Fehlerursache Nummer 1 bei Web Services ist schlicht weg die Infrastruktur. Die Web Service Technik an sich ist sehr robust, aber wenn der entsprechende Server nicht erreichbar oder überlastet ist – war die ganze Vorarbeit umsonst und man erhält eine Exception. In diesem Artikel beschreibe ich, wie man vorab einen Web Service prüfen kann.

 

 

Das Prinzip

Der supertolle Web Service Basistest bzw. Basischeck, der wirklich immer funktioniert und mein absoluter Favorit ist, besteht lediglich aus einem einfachen HTTP-Request. Dabei ruft man die WSDL oder den Endpoint des Web Services und fragt den HTTP-Statuscode ab.

 

HTTP-Statuscodes

Die wichtigsten HTTP-Statuscode sind:

  • HTTP 200 – OK : Der Web Service ist verfügbar und kann von einem Client gerufen werden.
  • HTTP 401 – Unauthorized : Der Web Service ist theoretisch verfügbar, aber der Client / das Programm besitzen keine, zu wenig oder die falschen Rechte.
  • HTTP 404 – Not Found : Der Web Service ist nicht verfügbar.

Generell kann man sagen:

Ein Web Service ist verfügbar, wenn der HTTP-Statuscode eines HTTP-Requests mit 2xx beginnt.

im Umkehrschluss bedeutet das:
Ein Web Service ist nicht verfügbar, wenn der HTTP-Statuscode mit 0 (Timeout), 3xx (Umleitung), 4xx (Client-Fehler) oder 5xx (Server-Fehler) beginnt.

 

Vor- und Nachteile des Basistests

Vorteile Nachteile
Der Test löst keine Operationen auf dem Server aus Der Server muss auf jeden Request antworten
Der Test kann jederzeit wiederholt werden Das Netzwerk wird belastet
Es muss kein Web Service Client erzeugt werden Der Test sagt wenig über die Auslastung des Servers aus
… …

 

Wann sollte getestet werden?

Es gibt mehrere Zeitpunkte an dem ein Web Service Basistest sinnvoll sein kann. Jedoch ist der entscheidende Faktor die Funktionalität des Web Services. Stellt der Web Service eine Schlüsselfunktion des Programms dar, sollte so früh wie möglich und regelmäßig die Verfügbarkeit des Web Service getestet werden. Bei einem negativen Ergebnis können so aufwendige Rechenoperationen oder Datenzugriffe (Festplatte, anderer Web Service, etc.) eingespart werden. Eine andere Möglichkeit wäre das Caching der gesammelten Daten, bis der Web Service wieder Verfügbar ist.
Bei einer trivialen Funktionalität sollte generell auf Verfügbarkeitstests verzichtet werden.

 

Beispielcode in Java

					String urlText = "http://blog.axxg.de/Url/zum/Web/Service?wsdl";

					int newHttpCode = 0;
					String newMessage = "";

					try{
						URL url = new URL(urlText);
						URLConnection connection = url.openConnection();
						// Timeout in Milisek (hier 1 Sek)
						connection.setConnectTimeout(1000);
						HttpURLConnection httpConnection = (HttpURLConnection) connection;

						newHttpCode = httpConnection.getResponseCode();
						newMessage = httpConnection.getResponseMessage();
					} catch (Exception e1){
						newHttpCode = 0;
						newMessage = e1.getMessage();
					}
					System.out.println("HTTP-Returncode: " + newHttpCode + " Message: " + newMessage);

 

Blog-Serie

Dieser Beitrag ist teil meiner Blog-Serie „gutes Web Service Design„. In dieser Serie berichte ich über Methoden und Möglichkeiten, um effektiv mit Web Services arbeiten zu können. Weitere Themen sind:

 

Copyright © 2012 AxxG – Alexander Gräsel



Verwandte Beiträge


Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.