mexc api in Java
-
Ich hab es hinbekommen.
- Es funktioniert mit einem einfachem GET-Request.
- POST-Requests funktionieren bei GET-Request nicht.
- Die API wird genauer unter Tab "SpotV2" beschrieben.
public static InputStream getGETInputStream(String apiStr, Map<String, String> map) throws IOException { String t = java.time.Instant.now().getEpochSecond() * 1000L + ""; System.out.println("t = " + t); String ak = "..."; String sk = "..."; URL url = URI.create("https://contract.mexc.com/" + apiStr).toURL(); HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setRequestMethod("GET"); urlConnection.setRequestProperty("ApiKey", ak); urlConnection.setRequestProperty("Request-Time", t); urlConnection.setRequestProperty("Signature", sign(new SignVo(t, ak, sk, null))); urlConnection.setUseCaches(false); urlConnection.setDoInput(true); urlConnection.setDoOutput(false); System.out.println("urlConnection = " + urlConnection); return urlConnection.getInputStream(); } public static void main(String[] args) throws IOException { try (BufferedReader br = new BufferedReader(new InputStreamReader(getGETInputStream("api/v1/private/account/asset/USDT", Map.ofEntries(Map.entry("currency", "USDT")))))) { String line; while ((line = br.readLine()) != null) { System.out.println("line = " + line); } } }
... Danke an alle, die dieses Thema (unnötigerweise) gelesen hatten.
-
Ohhhhhhhhhhhhhhhhhhhh, die negativen Bewertungen gehen wieder los...
-
@omggg sagte in mexc api in Java:
Ohhhhhhhhhhhhhhhhhhhh, die negativen Bewertungen gehen wieder los...
Entwickler von Brokersoftware sollten die Bedeutung von Bewertungen eigentlich kennen
MFG
-
Ja, hatte vergessen, dass hier keine infantile Nichtsnutze sind, sondern nur totale Experten...
Ne, mal im Ernst, nach einer Begründung für die schlechte Bewertung will ich gar nicht erst fragen...
-
@omggg sagte in mexc api in Java:
POST-Requests funktionieren bei GET-Request nicht.
WTF. Mir sind jedoch schon Server untergekommen, denen konnte man mit Request-Method ZITRONE einen Message-Body unterjubeln. Und tatsächlich steht im RFC, daß hierfür nicht die Request-Method ausschlaggebend ist sondern der Header Content-Length. So ist ein POST mit Content-Length: 0 genauso blödsinnig wie die Annahme daß es einen Message-Body mit Request-Method GET nicht gibt.
MFG
-
Ich weiß nicht genau, worauf du hinaus willst... ich bezog mich auf die API... nicht auf REST im Allgemeinen.
Aber ist doch jetzt gut, es funktioniert doch.
Vielleicht könnte dieses Thema gelöscht werden, wenn es stört.
-
@omggg sagte in mexc api in Java:
Ich weiß nicht genau, worauf du hinaus willst... ich bezog mich auf die API... nicht auf REST im Allgemeinen.
Einen Key im URL übertragen ist eine ganz schlechte Idee.
Aber ist doch jetzt gut, es funktioniert doch.
Verschlüsselung funktioniert nur mit dem Inhalt. Also Header, Body. Also POST und nicht GET. Es sind DEINE Daten.
MFG
-
@_ro_ro sagte in mexc api in Java:
Es sind DEINE Daten.
Der Ansicht bin ich auch. Und morgen wird schönes Wetter ...
Glaube aber, ich komme gerade nicht weiter...
json = {"leverage":20,"symbol":"BTC_USDT","side":1,"vol":"0.0005","price":47500,"type":1,"openType":1} Fri Feb 09 21:33:10 CET 2024 { "code": 1002, "success": false, "message": "Contract not allow place order!" }
public static InputStream getPOSTInputStream(String apiStr, Map<String, Object> map) throws IOException { String t = java.time.Instant.now().getEpochSecond() * 1000L + ""; SortedMap<String, Object> treeMap = new TreeMap<>(map); JSONObject jo = new JSONObject(); treeMap.forEach(jo::put); double vol = (double) treeMap.remove("vol"); jo.put("vol", "0.0005"); String json = jo.toString(); System.out.println("json = " + json); byte[] postData = json.getBytes(StandardCharsets.UTF_8); int postDataLength = postData.length; URL url = URI.create("https://contract.mexc.com/" + apiStr).toURL(); HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setRequestMethod("POST"); urlConnection.setRequestProperty("Content-Type", "application/json"); urlConnection.setRequestProperty("Content-Length", Integer.toString(postDataLength)); urlConnection.setRequestProperty("ApiKey", ak); urlConnection.setRequestProperty("Request-Time", t); urlConnection.setRequestProperty("Signature", sign(new SignVo(t, ak, sk, json))); urlConnection.setUseCaches(false); urlConnection.setDoInput(true); urlConnection.setDoOutput(true); try (DataOutputStream wr = new DataOutputStream(urlConnection.getOutputStream())) { wr.write(postData); } return urlConnection.getInputStream(); }
Was ist denn nun wieder falsch? Die sign. scheint richtig zu sein (sonst gäbe es einen anderen Fehler), aber ich darf anscheinend keine order erstellen.
Liegt das an "Order (Under maintenance)"?
-
Moin... Man sollte vielleicht auch mal in das Kleingedruckte schauen (jaja, stets die AGB lesen, das hätte mein alter Prof gesagt :D)... "BTC_USDT" ist (noch) nicht für den automatischen Handel offen. Aber Bitcoin 2.0 könnte funktionieren, ich melde mich später noch mal.
-
Nee, das geht leider noch nicht. Hab es nachgelesen und zum Teil auch ausprobiert, das ist noch nicht verfügbar. Aber das erklärt natürlich auch, weshalb zurzeit nur das Spot-SDK angeboten wird.
Also... hier könnte zu.
-
@omggg sagte in mexc api in Java:
Nee, das geht leider noch nicht. Hab es nachgelesen und zum Teil auch ausprobiert, das ist noch nicht verfügbar. Aber das erklärt natürlich auch, weshalb zurzeit nur das Spot-SDK angeboten wird.
Natürlich. Einen HTTPS-Request auf DENEN ihre Seite kann man natürlich nur mit einen SDK entwickeln was DIE anbieten und natürlich nur mit einer ganz bestimmten PL. DAS! ist die Botschaft. Die hahmse doch nicht mehr alle.
MFG
-
@_ro_ro sagte in mexc api in Java:
DAS! ist die Botschaft.
Ich finde, du reagierst etwas über... da ist eben noch vieles unter Maintenance.
-
ach was. Bin halt etwas direkt manchmal
(hab einige Programme und Scripts mit vi geschrieben)Schönen Sonntag!
-
@_ro_ro sagte in mexc api in Java:
Schönen Sonntag!
Danke, Dir auch! Vielleicht liest man sich später noch mal.