# API Aufruf besser steuern, wie Fehler vermeiden



## OnDemand (7. Mai 2020)

Hallo Zusammen,

ich habe ein paar API angebunden bekomme aber dummerweise von so ziemlich allen immer mal wieder 500er oder I/O Error. Verbindungen werden zurückgewiesen, Server überlastet usw. Dabei sende ich nur kleine json Strings zum Server. 

Es sind verschiedene Provider auf die ich keinen Einfluss habe, wäre es sinnvoll nach jedem Aufruf Thead.sleep für 5 Millisekunden aufzurufen, dass der Server gegenüber nicht überlastet? Ist ziemlich ätzend.

Server/Hosting aufstocken ist leider keine Option


----------



## mihe7 (7. Mai 2020)

Von welcher Seite sprichst Du jetzt? Client oder Server?


----------



## LimDul (7. Mai 2020)

Und wie oft rufst du die auf?


----------



## kneitzel (7. Mai 2020)

Also einige kommerzielle APIs schützen sich gegen zu viele Aufrufe. Amazon ist da ein gutes Beispiel und da haben die Webservice calls in der Doku sogar klare Hinweise, wie oft diese aufgerufen werden dürfen.

Daher ist der Anbieter diesbezüglich zu prüfen. Und ob da ein kleiner sleep ausreicht hängt klar von Anbieter ab. 

Von der Amazon API für Verkäufer (einfach mal als Beispiel) ist es teilweise so, dass da bis zu 5 Sekunden zwischen zwei Aufrufen sein müssen (Produktsuche um ASIN zu bekommen), andere Aufrufe sind 1 oder 2 Mal pro Sekunde erlaubt ...


----------



## OnDemand (7. Mai 2020)

Ich als Client bekomme die Fehlermeldung vom der fremden API Serverumgebung. Solch eine Begrenzung gibt es nicht, kommt iwie aus dem Netzwerk oder Überlastungen. Aufgerufen wird ca jede Sekunde ein Update, nicht mal mehrere parallel. Bei einem Anbieter schicke ich 10k Updates hin, da läuft es durch, bei anderen muss ich immer und immer wieder beginnen. (Batchupdate nicht möglich)


----------



## LimDul (7. Mai 2020)

Dann bleibt dir nix übrig als
* Entweder beim Betreiber der API drauf drängen, dass die stabilere Systeme bereitstellen
* Beim Aufruf prüfen, ob er durchgeht und wenn nicht nach X Millisekunden es nochmal probieren.

Bist du 100% Sicher das es keine Begrenzung gibt?


----------



## OnDemand (7. Mai 2020)

Grad eben wieder :/ 
I/O error on POST request for "https://xxx": Unexpected end of file from server; nested exception is java.net.SocketException: Unexpected end of file from server


----------



## OnDemand (7. Mai 2020)

LimDul hat gesagt.:


> Bist du 100% Sicher das es keine Begrenzung gibt?


von der installierten Software gibt es keine Begrenzung, hab ich schon angefragt. Dann würde da auch irgendwas kommen wie "zu viele Aufrufe Blabla" so ist es auch bei Amazon wenn ich bei deinem Beispiel bleibe.


----------



## OnDemand (7. Mai 2020)

Mir kam grad noch eine Idee, dass die evtl Fail2Ban installiert haben, dass hat Plesk zb von haus aus im Hosting mein ich. Das reagiert ziemlich schnell wenn da eine IP permanent auf was zugreift.


----------



## mrBrown (7. Mai 2020)

Verhindert wirst du das nie gänzlich können, je nachdem was du selbst nutzt gibts aber zumindest Hilfe: Microprofile Fault Tolerance oder zB resilience4j oder Hystrix


----------



## kneitzel (7. Mai 2020)

Also bei Fail2Ban müsste in der Regel ein Failure im Logfile auftauchen. Und dann kommt gar kein Connect mehr durch, d.h. Deine Anfragen laufen alle gnadenlos auf einen Timeout schon beim Connect. Ebenso bei der Abwehr von DOS Angriffen.


----------



## OnDemand (8. Mai 2020)

JustNobody hat gesagt.:


> Also bei Fail2Ban müsste in der Regel ein Failure im Logfile auftauchen. Und dann kommt gar kein Connect mehr durch, d.h. Deine Anfragen laufen alle gnadenlos auf einen Timeout schon beim Connect. Ebenso bei der Abwehr von DOS Angriffen.


Hast Recht, fiel mir in der Nacht auch ein, der würde dann komplett blocken.

@mrBrown das liest sich ja auf den ersten Blick super. Ich nutze spring Boot, muss ich ich mir später unbedingt genauer ansehen. Der Gegenpart ist allerdings nicht Spring, das ist was PHP


----------



## mrBrown (8. Mai 2020)

NicoDeluxe hat gesagt.:


> Der Gegenpart ist allerdings nicht Spring, das ist was PHP


Der Gegenpart ist egal, das nutzt man auf Consumer-Seite


----------



## OnDemand (8. Mai 2020)

Super, was würdest du empfehlen von den dreien? Hystrix scheint mir aufwendiger


----------



## mrBrown (8. Mai 2020)

Mit Spring Boot dürfte aktuell das am besten klappen: https://github.com/resilience4j/resilience4j-spring-boot2-demo


----------



## OnDemand (8. Mai 2020)

wirklich? 😵 sieht mir am weit entferntesten von einfach aus


----------



## mrBrown (8. Mai 2020)

Öhm, das ist zB der Code zum mehrmals versuchen:

```
@Retry(name = "IrgendeinNameFürDenService")
public Objekt tueIrgendwas() {...}
```

Was hast du dir denn angeguckt?[/code]


----------



## thecain (8. Mai 2020)

mrBrown hat gesagt.:


> Mit Spring Boot dürfte aktuell das am besten klappen


Ist nicht Hystrix der "default" Circuit breaker bei SpringBoot?


----------



## mrBrown (8. Mai 2020)

thecain hat gesagt.:


> Ist nicht Hystrix der "default" Circuit breaker bei SpringBoot?


Kann gut sein, allerdings wird Hystrix ja nicht mehr geupdated und resilenence4j empfohlen


----------



## thecain (8. Mai 2020)

Hast Recht. Habe auch gerade nachgelesen. Hystrix unterstützt zwar Fallbacks, aber kein Retry


----------



## OnDemand (9. Mai 2020)

Bekomm es nichts ins Projekt. folgenden Eintrag in die POM hab ich gemacht:

aber @EnableRetry wird nicht erkannt, meckert ItelliJ. Hab es auf der Startklasse annotiert


```
<!-- https://mvnrepository.com/artifact/io.github.resilience4j/resilience4j-retry -->
        <dependency>
            <groupId>io.github.resilience4j</groupId>
            <artifactId>resilience4j-retry</artifactId>
            <version>1.4.0</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/io.github.resilience4j/resilience4j-circuitbreaker -->
        <dependency>
            <groupId>io.github.resilience4j</groupId>
            <artifactId>resilience4j-circuitbreaker</artifactId>
            <version>1.4.0</version>
        </dependency>
```


EDIT: IntelliJCache war schuld


----------

