Výpis hovorů přes API

[srsen]

Je to Váš názor, máte na něj samozřejmě právo... jenomže se zkuste na to také podívat z druhé strany. Co kdyby odorik řekl, že žádné API pro výpis hovorů dělat nebude .. A šmitec.
Podle mě nabízí odorik super ceny za volání, tarifikace 1+1 ideální a osobně se už těším na to, až převedu svoje SIM karty k nim..
L.

Já odorika nektitizuju, je super že api má, ale když už asi něco investoval do toho api, tak proč to nedotáhnout do konce aby se mu ta investice co nejdřív vrátila? Bez funkčních příkladů ho dokáže použít třeba jen 10 procent lidí ve srování s počtem, kterje by to použil když bude k dispozici třeba vzorovej web v php. Tohle je jako kdyby někdo vyrobil super auto, ale bez řadící páky, volantu a kol. Jasně, ti schopní by si řazení a řízení vymysleli a dodělali sami, ale většina by se na tohle super auto vykašlala a raději by si koupili mnohem horší, ale lehce použitelný.

[BTjacker]

je třeba to dělat metodou POST, nikoli GET..
GET metoda na api není vhodná, protože nechcete mít heslo v historii prohlížeče.

Mohu se zeptat proč tedy zjištění kreditu vyžaduje GET a pomocí POST nefunguje? Autorizace je v tomto případě také nutná a heslo zůstává v prohlížeči.

[Largon]

Mohu se zeptat proč tedy zjištění kreditu vyžaduje GET a pomocí POST nefunguje? Autorizace je v tomto případě také nutná a heslo zůstává v prohlížeči.

Dobrý den,
primárním kritériem pro výběr použité HTTP metody není to, zda si bude něco pamatovat prohlížeč, ale spíše se snažíme držet specifikace HTTP (respektive RESTových služeb) s ohledem na idempotenci operace.

[leosl]

Námět na vylepšení služeb odoriku..

Nebylo by možné zpřístupnit pouze "čtení" výpisu hovorů přímo z databáze ? V administaci povolit IP z které by se čtení provádělo..

L.

[Largon]

Ne, to opravdu možné doufám nikdy nebude. Databáze patří do vnitřní sítě a je chráněna firewallem tak, že zvenčí se k ní nikdo nedostane. To že se občas vyskytnou problémy jako například nedávno CVE-2012-2122 je myslím dostatečným důvodem.

[leosl]

Ne, to opravdu možné doufám nikdy nebude. Databáze patří do vnitřní sítě a je chráněna firewallem tak, že zvenčí se k ní nikdo nedostane. To že se občas vyskytnou problémy jako například nedávno CVE-2012-2122 je myslím dostatečným důvodem.

Přesně tuto odpověď jsem očekával.
Tak jinak, proč odorik neposkytne přes api nejenom formáty dat které již podporuje, ale i např. formát .sql , poměrně jednoduchým způsobem lze importovat do databáze.
Určitě by to zvýšilo atraktivnost služby.

L.

[xsouku04]

K čemu konkrétně to potřebujete a jaké výhody by to představovalo oproti přímému použití API?

[Largon]

Abych pravdu řekl, tak mě ani nenapadlo, že by někdo mohl něco takového chtít.

Pokud chcete data připravená přímo pro import do databáze, tak myslím, že by neměl být žádný problém s tím, vygenerovat si ten .sql soubor z našeho XML výstupu pomocí XSLT.

[Largon]

Cvičně jsem si to zkoušel a něco takového by snad mohlo stačit:

Kód: Vybrat vše

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0">

<xsl:output method="text" encoding="utf-8"/>
<xsl:strip-space elements="*"/>

<xsl:template match="call">
  <xsl:text>INSERT INTO calls (date, from, to) </xsl:text>
  <xsl:text>VALUES ('</xsl:text>
  <xsl:value-of select="date"/>
  <xsl:text>', '</xsl:text>
  <xsl:value-of select="source_number"/>
  <xsl:text>', '</xsl:text>
  <xsl:value-of select="destination_number"/>
  <xsl:text>');
</xsl:text>
</xsl:template>

</xsl:stylesheet>

[xtonda]

Pod .sql si máme představit co? Soubor se sadou inserttů? To bys pak musel dodržet jména tabulek a sloupců tak jak je zavede Odorik, nehledě na množství SQL dialektů.

Máš tam CSV, tak si ho napoj jako externí tabulku a v SQL si s tím dělej co uznáš za vhodné.