API 1.0
Filip Tepper
Ale nie musi. Czekamy na uwagi i propozycje.
--
Filip Tepper
a0
0. Co dokładnie się zmieniło a co zostało dodane, bo tak patrzę i
ogólnie to się pokrywa ;)
a na serio:
1. Które metody będą wymagały uwierzytelniania, a które nie?
2. jaki format JSON będą miały odpowiedzi zawierające wiadomości
kierowane?
3. czy zmieni się format JSON odpowiedzi w metodach które pokrywają
sie z obecnym API?
4. Co się rozumie przez 'Twitter' w API? Czy public timeline będzie
połączony z zasobem /bliposphere? Czy będzie możliwość rozróżnienia
blipnięć i tweetnięć?
Marcin Ciunelis
> API 1.0 może wyglądać tak: http://trac6.assembla.com/blip-api/
>
> Ale nie musi. Czekamy na uwagi i propozycje.
moze by tak search?
i avatar zawsze pod tym samym adresem (np: /users/:login/avatar_:size.jpg
pozdro
m.
Filip Tepper
> moze by tak search?
Użytkowników? Blipnięć?
> i avatar zawsze pod tym samym adresem (np: /users/:login/avatar_:size.jpg
To będzie - jest już w kodzie, ale czekam z deployem na po wulkanizacji oponki.
--
Filip Tepper
Krzysztof Młynarski
> API 1.0 mo�e wygl�da� tak: http://trac6.assembla.com/blip-api/
>
> Ale nie musi. Czekamy na uwagi i propozycje.
>
A mnie tradycyjnie brakuje metody, kt�ra zwraca "czerwon� ramk�", czyli
umo�liwia sprawdzenie, czy dany u�ytkownik nie ma przypadkiem statusu
"online". Skoro na WWW pojawia si� taka ramka, to znaczy, �e gdzie� pod
spodem istnieje proste API do tego, kt�re taki status zwraca.
Tak, wiem, �e dotyczy to tylko u�ytkownik�w wisz�cych via WWW itd. Ale
tak czy owak, to by by�o bardzo przydatne.
Pozdrawiam,
-K.
Plugawy
On 9 Lut, 10:00, Filip Tepper <fi...@tepper.pl> wrote:
> API 1.0 może wyglądać tak:http://trac6.assembla.com/blip-api/
>
> Ale nie musi. Czekamy na uwagi i propozycje.
Na Blipie napisałeś, że "include" wypada - jak rozumiem wszystko
bedzie upakowane tak jak twitterze? (czyli pobierając status(-y) mamy
od razu dostęp do obiektu user, pictures etc?)
Co do statusu "online" jak to się ma do użytkowników aplikacji
klienckich? Nie ma czegoś takiego jak "online" w tym przypadku.
Można mieć coś w stylu http://api.blip.pl/presence i symulować bycie
online poprzez wysyłanie czegoś (czego?) gdy loguję się używając
aplikacji klienckiej, oraz wysyłanie czegoś gdy ją zamykam.
IMO jest to zbędne - nie widziałem tego w żadnej innej usłudze tego
typu.
--
filthy
a0
kokpit imho. Blipi używa API nonstop co minutę, i nonstop miga jako
online/offline.
On Feb 9, 12:39 pm, Plugawy <lukaszkore...@gmail.com> wrote:
> On 9 Lut, 10:00, Filip Tepper <fi...@tepper.pl> wrote:
>
> > API 1.0 może wyglądać tak:http://trac6.assembla.com/blip-api/
>
> > Ale nie musi. Czekamy na uwagi i propozycje.
>
> Na Blipie napisałeś, że "include" wypada - jak rozumiem wszystko
> bedzie upakowane tak jak twitterze? (czyli pobierając status(-y) mamy
> od razu dostęp do obiektu user, pictures etc?)
>
> Co do statusu "online" jak to się ma do użytkowników aplikacji
> klienckich? Nie ma czegoś takiego jak "online" w tym przypadku.
> Można mieć coś w styluhttp://api.blip.pl/presencei symulować bycie
Marcin Ciunelis
> On Feb 9, 2010, at 11:37 AM, Marcin Ciunelis wrote:
>
>> moze by tak search?
>
> Użytkowników? Blipnięć?
>
blipniec, najlepiej z jakimis filtrami po dacie, uzytkowniku plus
wyrazenia logiczne (AND, OR, NOT itp)
m.
Marcin Maciukiewicz
On 9 Feb 2010, at 10:00, Filip Tepper wrote:
> API 1.0 może wyglądać tak: http://trac6.assembla.com/blip-api/
>
> Ale nie musi. Czekamy na uwagi i propozycje.
Czy wprowadzicie atrybuty dla geolokalizacji blipniecia (long/lat) czy pozostawiacie osadzane mapki?
ciukes.
Marcin Maciukiewicz
API 1.0 może wyglądać tak: http://trac6.assembla.com/blip-api/
Ale nie musi. Czekamy na uwagi i propozycje.
Marcin Maciukiewicz
> bedzie upakowane tak jak twitterze? (czyli pobierając status(-y) mamy
> od razu dostęp do obiektu user, pictures etc?)
>
> Co do statusu "online" jak to się ma do użytkowników aplikacji
> klienckich? Nie ma czegoś takiego jak "online" w tym przypadku.
> Można mieć coś w stylu http://api.blip.pl/presence i symulować bycie
> online poprzez wysyłanie czegoś (czego?) gdy loguję się używając
> aplikacji klienckiej, oraz wysyłanie czegoś gdy ją zamykam.
> IMO jest to zbędne - nie widziałem tego w żadnej innej usłudze tego
> typu.
ciukes.
Łukasz
>> Na Blipie napisa�e�, �e "include" wypada - jak rozumiem wszystko
>> bedzie upakowane tak jak twitterze? (czyli pobieraj�c status(-y) mamy
>> od razu dost�p do obiektu user, pictures etc?)
>>
>> Co do statusu "online" jak to si� ma do u�ytkownik�w aplikacji
>> klienckich? Nie ma czegoďż˝ takiego jak "online" w tym przypadku.
>> Mo�na mie� co� w stylu http://api.blip.pl/presence i symulowa� bycie
>> online poprzez wysy�anie czego� (czego?) gdy loguj� si� u�ywaj�c
>> aplikacji klienckiej, oraz wysy�anie czego� gdy j� zamykam.
>> IMO jest to zb�dne - nie widzia�em tego w �adnej innej us�udze tego
>> typu.
> Bardzo przydatna bylaby informacja kiedy uzytkownik ostatnio wykonal
> jakas aktywnosc ("2 minuty temu", "3 miesiace temu" itd.).
>
[{ body : "blah",
user : {
login : "blomp",
last_action :2903583094, //timestamp, nikt nie lubi parsowaďż˝
dat ;-)
avatar: {
url : http://avatar./blip.com/img.jpg
id : 49
}
},
pictures : [], //nawet je�li ich nie ma fajnie mie� pust� tablic�
/// itd...
},... ]
Filip Tepper
> 0. Co dokładnie się zmieniło a co zostało dodane, bo tak patrzę i
> ogólnie to się pokrywa ;)
Changeloga nie mamy - ale jak chodzi o listę metod to zostały dodane przede wszystkim te, do ignorowania/tagów w kontekście użytkownika.
Chcemy też uporządkować kilka metod tak, żeby było ich mniej. Dlatego też pobieranie czy usuwanie wszystkich wiadomości ma się odbywać przez jedną metodę.
> a na serio:
> 1. Które metody będą wymagały uwierzytelniania, a które nie?
Ja będę głosował za tym, że wszystkie/większość. Jeszcze nie wiemy.
> 2. jaki format JSON będą miały odpowiedzi zawierające wiadomości
> kierowane?
Mam to zaznaczone na wewnętrznym wiki jako - do opracowania -. Pracujemy nad kilkoma rzeczami w backendzie, które być może trafią do API więc nie możemy jeszcze na 100% ustalić formatu.
> 3. czy zmieni się format JSON odpowiedzi w metodach które pokrywają
> sie z obecnym API?
Tak, będzie nowa struktura JSON-a.
> 4. Co się rozumie przez 'Twitter' w API? Czy public timeline będzie
> połączony z zasobem /bliposphere? Czy będzie możliwość rozróżnienia
> blipnięć i tweetnięć?
API Blipa będzie kompatybilne z API Twittera. Czyli - blipnięcia będą serwowane w formacie zgodnym z API Twittera.
Jeśli masz klienta Twittera, który akceptuje alternatywne adresy API (konsolowy Termtter, Tweetie i Twitterific na iPhone'a) to możesz sprawdzić jak by to mniej więcej działało podając jako adres http://blip-twitter.heroku.com/
--
Filip Tepper
Filip Tepper
> A mnie tradycyjnie brakuje metody, która zwraca "czerwoną ramkę", czyli
> umożliwia sprawdzenie, czy dany użytkownik nie ma przypadkiem statusu
> "online". Skoro na WWW pojawia się taka ramka, to znaczy, że gdzieś pod
> spodem istnieje proste API do tego, które taki status zwraca.
>
> Tak, wiem, że dotyczy to tylko użytkowników wiszących via WWW itd. Ale
> tak czy owak, to by było bardzo przydatne.
Dopiszę, ale nie obiecuję, że będzie to dostępne.
--
Filip Tepper
Filip Tepper
> Na Blipie napisałeś, że "include" wypada - jak rozumiem wszystko
> bedzie upakowane tak jak twitterze? (czyli pobierając status(-y) mamy
> od razu dostęp do obiektu user, pictures etc?)
Dokładnie.
> Co do statusu "online" jak to się ma do użytkowników aplikacji
> klienckich? Nie ma czegoś takiego jak "online" w tym przypadku.
> Można mieć coś w stylu http://api.blip.pl/presence i symulować bycie
> online poprzez wysyłanie czegoś (czego?) gdy loguję się używając
> aplikacji klienckiej, oraz wysyłanie czegoś gdy ją zamykam.
> IMO jest to zbędne - nie widziałem tego w żadnej innej usłudze tego
> typu.
Aktualnie działa to tak, że każda aktywność przez szeroko rozumiane WWW (czyli także API) jest zapisywana (na 10 sekund) - tego nie chcemy zmieniać.
Poprzez online przez API rozumiemy wykonanie zapytania do serwera Blipa.
--
Filip Tepper
Filip Tepper
>>> moze by tak search?
>>
>> Użytkowników? Blipnięć?
>
> blipniec, najlepiej z jakimis filtrami po dacie, uzytkowniku plus
> wyrazenia logiczne (AND, OR, NOT itp)
Chcielibyśmy, ale... ;-)
Na razie musi to trochę poczekać, mamy zbyt dużo innych rzeczy do wdrożenia.
--
Filip Tepper
Filip Tepper
> Czy wprowadzicie atrybuty dla geolokalizacji blipniecia (long/lat) czy pozostawiacie osadzane mapki?
Wprowadzimy - ale raczej nie w tej wersji API i nie podam też konkretnego terminu bo pozmieniały się nam priorytety.
Osadzane mapki zostaną pewnie do redesignu.
--
Filip Tepper
Filip Tepper
Ale nie musi. Czekamy na uwagi i propozycje.
Brakuje mi metody "since" pobierajacej informacje z uzyciem daty. Mam na mysli:GET /.../since/:data
Filip Tepper
> Bardzo przydatna bylaby informacja kiedy uzytkownik ostatnio wykonal jakas aktywnosc ("2 minuty temu", "3 miesiace temu" itd.).
user.current_status.created_at?
--
Filip Tepper
Marcin Maciukiewicz
wystarczajace.
jesli jednak macie mozliwosc to rozwazcie to ze dodanie/usuniecie tagu/obserwowanego to takze aktywnosc,
pobranie wiadomosci z kokpitu rowniez.
ciukes.
Marcin Maciukiewicz
Osadzane mapki zostaną pewnie do redesignu.
Filip Tepper
>> user.current_status.created_at?
> wystarczajace.
> jesli jednak macie mozliwosc to rozwazcie to ze dodanie/usuniecie tagu/obserwowanego to takze aktywnosc,
> pobranie wiadomosci z kokpitu rowniez.
Sound like 1984. ;-)
--
Filip Tepper
Plugawy
On Feb 9, 12:45 pm, Filip Tepper <fi...@tepper.pl> wrote:
> On Feb 9, 2010, at 12:39 PM, Plugawy wrote:
>
> > Na Blipie napisałeś, że "include" wypada - jak rozumiem wszystko
> > bedzie upakowane tak jak twitterze? (czyli pobierając status(-y) mamy
> > od razu dostęp do obiektu user, pictures etc?)
>
> Dokładnie.
Świetnie, zatem jeden ficzer rikłest (też prosto z twittera):
wysyłając ">" lub ">>" czy można opcjonalnie dołączyć id wiadomość na
która się odpowiada?
Krzysztof Młynarski
> On Feb 9, 2010, at 12:19 PM, Krzysztof M�ynarski wrote:
>
>
>> A mnie tradycyjnie brakuje metody, kt�ra zwraca "czerwon� ramk�", czyli
>> umo�liwia sprawdzenie, czy dany u�ytkownik nie ma przypadkiem statusu
>> "online". Skoro na WWW pojawia si� taka ramka, to znaczy, �e gdzie� pod
>> spodem istnieje proste API do tego, kt�re taki status zwraca.
>>
>> tak czy owak, to by by�o bardzo przydatne.
>>
>
> Dopisz�, ale nie obiecuj�, �e b�dzie to dost�pne
;-) Jak nie b�dzie to b�d� o tym przypomina� dalej.. a� kto� w ko�cu
powie: ok, ju� lepiej da� t� funkcjonalno�� w API, to nie b�d� marudzili. :D
Pozdrawiam,
-K.
Marcin Maciukiewicz
neeeeee. chodzi mi o to zeby czas wykonania ostatniej oaktywnosci faktycznie odzwierciedlal czas wykonania ostatniej aktywnosci.
ciukes.
Marcin Maciukiewicz
+1
Marcin Maciukiewicz
On 9 Feb 2010, at 14:06, Krzysztof Młynarski wrote:
> W dniu 2010-02-09 13:41, Filip Tepper pisze:
> ;-) Jak nie będzie to będę o tym przypominał dalej.. aż ktoś w końcu
> powie: ok, już lepiej dać tą funkcjonalność w API, to nie będą marudzili. :D
wygodniejsze w uzyciu jest posiadanie informacji o czasie wykonania ostatniej aktywnosci przez uzytkownika.
ciukes.
Łukasz
>
> On 9 Feb 2010, at 14:06, Krzysztof M�ynarski wrote:
>
>> W dniu 2010-02-09 13:41, Filip Tepper pisze:
> wygodniejsze w uzyciu jest posiadanie informacji o czasie wykonania ostatniej aktywnosci przez uzytkownika.
>
;-)
Krzysztof Młynarski
> On 9 Feb 2010, at 14:06, Krzysztof M�ynarski wrote:
>
>> W dniu 2010-02-09 13:41, Filip Tepper pisze:
>>
>>
> wygodniejsze w uzyciu jest posiadanie informacji o czasie wykonania ostatniej aktywnosci przez uzytkownika.
>
Zadaniczo nie mam nic przeciwko temu, �eby�my mieli both of them!
Dlaczego? Ano kod bez konieczno�ci parsowania i por�wnywania daty jest
po prostu szybszy.
Wystarczy odpytaďż˝ i mamy logikďż˝ bitowďż˝ 1 = TAK, 0 = NIE ;-))) Zresztďż˝
pisa�em - chodzi mi o udost�pnienie w API informacji, na podstawie,
kt�rej, w interfejsie webowym generowana jest "czerwona ramka" dooko�a
awatarka. :)
A to o czym piszesz te�, jak najbardziej, uwa�am za u�yteczne i popieram
w 100% :-)))
Pozdrawiam,
-K.
Filip Tepper
> Świetnie, zatem jeden ficzer rikłest (też prosto z twittera):
> wysyłając ">" lub ">>" czy można opcjonalnie dołączyć id wiadomość na
> która się odpowiada?
Będzie to, ale jeszcze nie teraz.
--
Filip Tepper
Filip Tepper
>> Dopiszę, ale nie obiecuję, że będzie to dostępne
>
> ;-) Jak nie będzie to będę o tym przypominał dalej.. aż ktoś w końcu
> powie: ok, już lepiej dać tą funkcjonalność w API, to nie będą marudzili. :D
To akurat bardziej decyzja product ownera niż techniczna.
--
Filip Tepper
Filip Tepper
> Zadaniczo nie mam nic przeciwko temu, żebyśmy mieli both of them!
> Dlaczego? Ano kod bez konieczności parsowania i porównywania daty jest
> po prostu szybszy.
> Wystarczy odpytać i mamy logikę bitową 1 = TAK, 0 = NIE ;-))) Zresztą
> pisałem - chodzi mi o udostępnienie w API informacji, na podstawie,
> której, w interfejsie webowym generowana jest "czerwona ramka" dookoła
> awatarka. :)
No nie, dla prostej pierdoły na pewno będziemy mnożyć metod. ;-)
--
Filip Tepper
Marcin Maciukiewicz
> Zadaniczo nie mam nic przeciwko temu, żebyśmy mieli both of them!
> Dlaczego? Ano kod bez konieczności parsowania i porównywania daty jest
> po prostu szybszy.
> Wystarczy odpytać i mamy logikę bitową 1 = TAK, 0 = NIE ;-))) Zresztą
> której, w interfejsie webowym generowana jest "czerwona ramka" dookoła
> awatarka. :)
>
> A to o czym piszesz też, jak najbardziej, uważam za użyteczne i popieram
> w 100% :-)))
niepotrzebne mnozenie metod.
jesli masz w reku czas wykonania ostatniej aktywnosci to dodajesz do tego powiedzmy 2 minuty i masz
pojecie o tym czy uzytkownik jest aktywny czy nie.
Powiedz prosze do czego jest ci wogole potrzebna "czerwona ramka" ?
ciukes.
Krzysztof Młynarski
>> Zadaniczo nie mam nic przeciwko temu, �eby�my mieli both of them!
>> po prostu szybszy.
>> Wystarczy odpytaďż˝ i mamy logikďż˝ bitowďż˝ 1 = TAK, 0 = NIE ;-))) Zresztďż˝
>> kt�rej, w interfejsie webowym generowana jest "czerwona ramka" dooko�a
>> awatarka. :)
>>
>> A to o czym piszesz te�, jak najbardziej, uwa�am za u�yteczne i popieram
>> w 100% :-)))
>>
> niepotrzebne mnozenie metod.
> jesli masz w reku czas wykonania ostatniej aktywnosci to dodajesz do tego powiedzmy 2 minuty i masz
> pojecie o tym czy uzytkownik jest aktywny czy nie.
>
> Powiedz prosze do czego jest ci wogole potrzebna "czerwona ramka" ?
>
Np. do tego, �eby aplikacja mog�a wys�a� co� u�ytkownikowi - je�li on
jest on-line lub odpu�ci� sobie, je�li nie jest.
Inne zastosowanie, np. sprawdzenie, czy dany osobnik pojawiďż˝ siďż˝ juďż˝
dzi� na Blipie.. i je�li tak, to akcja.. je�li nie - czekanie na
nast�pn� okazj�... itd. itd.
Pozdrawiam,
-K.
Marcin Maciukiewicz
wszystko zalatwia informacja o czasie kiedy uzytkownik wykonal ostatnia aktywnosc.
Np. do tego, żeby aplikacja mogła wysłać coś użytkownikowi - jeśli on
jest on-line lub odpuścić sobie, jeśli nie jest.
Inne zastosowanie, np. sprawdzenie, czy dany osobnik pojawił się już
dziś na Blipie.. i jeśli tak, to akcja.. jeśli nie - czekanie na
następną okazję... itd. itd.
Krzysztof Młynarski
Np. do tego, �eby aplikacja mog�a wys�a� co� u�ytkownikowi - je�li on
jest on-line lub odpu�ci� sobie, je�li nie jest.
Inne zastosowanie, np. sprawdzenie, czy dany osobnik pojawiďż˝ siďż˝ juďż˝
dzi� na Blipie.. i je�li tak, to akcja.. je�li nie - czekanie na
nast�pn� okazj�... itd. itd.
wszystko zalatwia informacja o czasie kiedy uzytkownik wykonal ostatnia aktywnosc.
OK, poddaj� si�! :) Jeden PIES... byle by�o co� takiego w API.
Pozdrawiam,
-K.
Rafał Cieślak
informacje o użytkowniku czy będzie nadal tak, jak jest? Aktualnie nie
są wysyłane informacje o np. stronie WWW.
Filip Tepper
> Metody /profile i /users/:login/profile będą zwracały wszystkie
> informacje o użytkowniku czy będzie nadal tak, jak jest? Aktualnie nie
> są wysyłane informacje o np. stronie WWW.
Więcej informacji i bardziej koherentnie - zasób /profile będzie
zwracał te same dane, które będą dołączone do wiadomości jako opis
autora.
--
Filip Tepper
Przemysław Pawliczuk
Hmm, w sumie to i zewnętrzne klienty mogłyby taką flagę ustawiać - np. Co każde żądanie wymagające autoryzacji? Myślę, że to takie ciężkie by nie było. ;)
A jeśli chodzi o sposób pobierania - to proponowałbym albo osobną metodę, albo dopięcie do którejś już istniejącej.
W porównaniu z botami GG/XMPP mamy tu aktywny przesył (taktowanie co N sekund w celu aktualizacji, a nie jednostronny push, jak to jest w przypadku botów), więc można IMHO poszaleć.
Pozdrawiam,
Przemysław "eRIZ" Pawliczuk
--
JID: eriz//pcinside.pl
www: http://eriz.pcinside.pl
Wiktor Gworek
Inne:
1) Czy istnieje możliwość nie skracania linków podczas dodawania
blipów? Wystarczyłby ekstra parametr, który by dodawał mapę skróconych
linków do ich pełnych adresów. Zaoszczędza się dzięki temu ekstra
żądania i pozwala klientom na detekcje linków (map, filmów itd).
2) Planujecie coś ekstra? Nudą powiewa API. Jaka geolokalizacja,
"custom annotations" do poszczególnych blipów?
W.
Filip Tepper
> Jak tam status nowego API? Kiedy planujecie wypuścić je do testowania?
Na razie niestety nie planujemy. Sporo przepisujemy póki co.
> 1) Czy istnieje możliwość nie skracania linków podczas dodawania
> blipów? Wystarczyłby ekstra parametr, który by dodawał mapę skróconych
> linków do ich pełnych adresów. Zaoszczędza się dzięki temu ekstra
> żądania i pozwala klientom na detekcje linków (map, filmów itd).
Nie, to chyba zbyt niszowa funkcjonalność.
> 2) Planujecie coś ekstra? Nudą powiewa API. Jaka geolokalizacja,
> "custom annotations" do poszczególnych blipów?
Planujemy. ;-)
--
ft
Wiktor Gworek
nimi (GET /mesages).
Przy okazji, poniższe 3 operacje wydają się być zbędne:
* POST /statuses
* POST /directed_messages
* POST /private_messages
--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie "blip-devel".
Aby zamieszczać posty w tej grupie, wyślij e-mail na adres blip-...@googlegroups.com.
Aby anulować subskrypcję tej grupy, wyślij e-mail na adres blip-devel+...@googlegroups.com.
Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/blip-devel?hl=pl.
Filip Tepper
> Wiadomości skierowane i prywatne. Fajnie byłoby mieć jeden strumień z
> nimi (GET /mesages).
> Przy okazji, poniższe 3 operacje wydają się być zbędne:
> * POST /statuses
> * POST /directed_messages
> * POST /private_messages
DirectedMessage/PrivateMessage może ona mieć również 160 znaków (bez
adresata).
--
ft
Wiktor Gworek
2010/4/19 Wiktor Gworek <wiktor...@gmail.com>:
Zobaczymy jak wyjdzie to z nowym layoutem, prawdopodobnie się pojawi.
> Wiadomości skierowane i prywatne. Fajnie byłoby mieć jeden strumień z
> nimi (GET /mesages).
> Przy okazji, poniższe 3 operacje wydają się być zbędne:Nie - dzięki temu, że możesz wysłać bezpośrednio
> * POST /statuses
> * POST /directed_messages
> * POST /private_messages
DirectedMessage/PrivateMessage może ona mieć również 160 znaków (bez
adresata).
Filip Tepper
>> > Przy okazji, poniższe 3 operacje wydają się być zbędne:
>> > * POST /statuses
>> > * POST /directed_messages
>> > * POST /private_messages
>>
>> Nie - dzięki temu, że możesz wysłać bezpośrednio
>> DirectedMessage/PrivateMessage może ona mieć również 160 znaków (bez
>> adresata).
>>
> <nit>
> Idę o zakład, że ponad 90% nowych blipów poprzez api to POST /updates.
> </nit>
Jednak niektórzy z tego korzystają (my sami także), więc ma to swoje
praktyczne uzasadnienie.
--
ft
Wiktor Gworek
Czy dla tych żądań przy braku autentykacji mógłby być zwracany kod 401
z nagłówkiem WWW-Authenticate?
Tak obecnie jest przy innych metodach, np.
curl -v -H'X-Blip-api: 0.02' -F'update[body]=hello' http://api.blip.pl/updates