Próbowałem restful.js, próbowałem jQuery REST client, aż ostatecznie dałem sobie spokój. Dla mnie były jakieś trudne/ciężkie w użyciu. A czym powinien być REST client? Cienkim wrapperem na dowolnego klienta HTTP, który gada z dowolnym url-em.

Na własne potrzeby założyłem, że:

• interfejs ma być banalnie prosty w użyciu
• wystarczy obsługa tylko content type application/json
• ma być obsługa nagłówków, także defaultowych (żeby się nie powtarzać)
• dozwolona jest zależność od jQuery (można się tego względnie łatwo wyzbyć)

Powstał prototyp:

var RestAPI = function(url, params) {
    var absoluteUrlPattern = /^https?:\/\//i,
        self=this,
        params = params || {};

    this.defaultHeaders = params.headers || {};
    this.url = url;

    function isAbsoluteUrl(url) {
        return absoluteUrlPattern.test(url);
    }

    function resourceToUrl(resource) {
        resource = resource || '';
        if(isAbsoluteUrl(resource)) {
            return resource;
        } else {
            return self.url+'/'+resource;
        }
    }

    function makeResponseObject(jqXhr, data) {
        var headers = {},
            headersList = jqXhr.getAllResponseHeaders().split('\r\n');
        $.each(headersList, function(i, headerStr) {
            var headerTuple = headerStr.split(': ');
            if(headerTuple[0]) {
                headers[headerTuple[0].toLowerCase()] = headerTuple[1];
            }
        });
        return {
            status: jqXhr.status,
            statusText: jqXhr.statusText,
            headers: headers,
            data: data 
        };
    }

    function doMethod(type, resource, data, headers) {
        var dfr = $.Deferred(),
            completeHeaders = $.extend({}, self.defaultHeaders, headers);

        $.ajax({
            url: resourceToUrl(resource),
            type: type,
            dataType: 'json',
            contentType: 'application/json',
            headers: completeHeaders,
            data: typeof(data)!=='undefined' && data!==null ? JSON.stringify(data) : null
        }).then(function(respData,respStatus,jqXhr) {
            dfr.resolve(respData, makeResponseObject(jqXhr, respData));
        }, function(jqXhr) {
            dfr.reject(makeResponseObject(jqXhr));
        });
        return dfr.promise();
    };


    this.get = function(resource, params, headers) {
        return doMethod('GET', resource, params, headers);
    }

    this.post = function(resource, payload, headers) {
        return doMethod('POST', resource, payload, headers);
    }

    this.put = function(resource, payload, headers) {
        return doMethod('PUT', resource, payload, headers);
    }

    this.patch = function(resource, payload, headers) {
        return doMethod('PATCH', resource, payload, headers);
    }

    this['delete'] = function(resource, headers) {
        return doMethod('DELETE', resource, null, headers);
    }

}

Działa? Działa, i to ciekawie.

Przykład - kto mnie śledzi na GitHub?

var github = new RestAPI('https://api.github.com');

github.get('users/marcinn').then(function(user) {
    github.get(user.followers_url).then(function(followers) {
        console.log(followers);
    });
});

Koniec, kropka. Prosto i na temat. Pobawta się sami na plunkr.

Jak kogo interesuje - publikuję na licencji "Brać! Mać..." oczywiście bez żadnej gwarancji. Wspomnijta w creditsach, że był taki Nowak, któremu to się klepać kodu nie chciało.

I jeszcze jedno - skoro się niektórzy chwalą filesize, to ja też podam:

• Original: 2370 bytes
• Gzipped: 764 bytes

Niech przebijają.

A AngularJS i jego ngResource albo nawet Restangular? Głupotą jest mapowanie REST na CRUD (albo stosowanie active record). W REST mamy dobrze określone VERBS. Nie ma wśród nich save. I tyle w temacie.

Znalazłem ostatnio dwa ciekawe wpisy traktujące o architekturze REST. Pierwszy z nich jest autorstwa niezastąpionego Martina Fowlera, który ciekawie przedstawił drogę od prostych usług typu RPC aż po podstawy RESTful (ale nie samego REST-a). Zdecydowanie ułatwia przejście od jednej do drugiej koncepcji: http://martinfowler.com/articles/richardsonMaturityModel.html

Z kolei drugą perełką jest wpis Ryana Tomayko, programisty GitHuba i Heroku, który wytłumaczył idee RESTful (wirtualnej?) żonie. Niestety środowisko gender zaatakowało Ryana i autor usunął artykuł-wywiad, ale na szczęście (w tym wypadku) Internet zachował jego kopie. Znajdziecie takową m.in. na archive.org: http://web.archive.org/web/20130116005443/http://tomayko.com/writings/rest-to-my-wife

Miłej lektury!

Jestem wprost zafascynowany i rozpływam się jak masło w rondlu, kiedy otrzymuję zamówione newslettery. Jest spora szansa na to, że podobnie mają inni ludzie - zawodowcy, pasjonaci, hobbyści. Może są to nawet cholerne tysiące ludzi, a biorąc pod uwagę prasę drukowaną to i miliony istnień, które chcą dowiedzieć się co się w danym środowisku, produkcie czy dziedzinie nauki dzieje, a co jest planowane i wkrótce się wydarzy. Przyjęło się, że czytamy newsy, u Putina новости czy też известие, a po naszemu nowości a nawet niusy, choć właściwie neologizmy mnie drażnią. Toteż towarzyszy tym newsletterom pewien stopień podniecenia, doprowadzają mnie one niemal do rozkoszy, aby w końcu ten jeden szczególny - od Polish Python Coders Group - działał jak kubeł zimnej wody. Albo nie - jak przegnanie człowieka na golasa przez wartką, górską rzekę o piątej nad ranem.

Nowości, to są rzeczy i wydarzenia nowe, nadchodzące, naturalnie w opozycji do przeszłości, czasów zamierzchłych i zdarzeń minionych. I do prawdy nie mogę zrozumieć dlaczego z uporem maniaka PPCG rozsyła "nowości" z przeszłości. Tak! Są to zamierzchłości publikowane jako nowości, tytułowane przewrotnie "newsletterem" (list z nowościami, jakby nie patrzeć), z których dowiedzieć się możemy, że "za dwa dni było spotkanie koderów Pythona w Osrajdowie Małym" albo że "w minionym miesiącu będzie można wziąć udział w konkursie".

Kilkakrotnie pisałem na adres e-mail podany w newsletterze, ale po braku reakcji wnoszę, iż prawdopodobnie lądują one zawsze w przyszłości i nigdy nie zostaną odczytane, chyba że ktoś w przyszłości zorientuje się, że rozsyłali informacje z przeszłości, i wówczas może nastąpić jakieś załamanie czasoprzestrzeni, w końcu pewne fakty oraz moje listy dotrą do oświeconych osób, a pastletter stanie się prawdziwym newsletterem.

To niezła wizytówka środowiska programistów Python. Profesjonalizm pełną gębą. A szczególnie kole w oczy to marne forum postawione na PHP-ie, które rozsyła hasła plain textem w mailu potwierdzającym rejestrację. Razem z rozwalającą się stroną PySilesia dumnie realizują cele statutowe polegające na promowaniu Pythona. Chyba Monty Pythona. Latającego cyrku.

Deadline24 to międzynarodowy maraton programistyczny organizowany przez firmę Future Processing, który polega na rywalizacji trzyosobowych drużyn zmagających się z zadaniami algorytmicznymi. Już po raz siódmy pasjonaci informatyki będą mieć szansę wykazać się swoją wiedzą, kreatywnością oraz wytrwałością, pracując nad zadaniami konkursowymi przez 24 godziny. Rejestracja trzyosobowych drużyn potrwa do 26 lutego 2015 roku. Zapisy odbywają się za pośrednictwem formularza na stronie https://deadline24.pl/rejestracja/. Eliminacje rozpoczną się 1 marca 2015 roku punktualnie o 9.00. Przez 5 godzin zegarowych drużyny będą zmagać się z rozwiązywaniem zadań i generowaniem odpowiedzi, ocenianych przez serwer sprawdzający. Ten etap przebiega zdalnie.

Do finału zapraszane są najlepsze drużyny spośród tych, które wzięły udział w eliminacjach. Finał odbędzie się w dniach 7-8 kwietnia 2015 roku i potrwa nieprzerwanie przez 24 godziny. Wyróżnikiem maratonu Deadline24, poza nietypową formułą zadań konkursowych, których głównymi bohaterami są żukoskoczki, jest organizowanie go w miejscach wpisujących się w tradycję województwa śląskiego. Edycja 2012 i 2013 miała swój finał w Zabytkowej Kopalni Węgla Kamiennego Guido, 320 metrów pod ziemią, a w roku ubiegłym konkurs odbywał się w Zabytkowej Kopalni „Ludwik” w Zabrzu. Organizatorzy zapewniają, że tegoroczna edycja także zaskoczy uczestników wyjątkową oprawą oraz cennymi nagrodami!

Zeszłoroczna edycja maratonu zgromadziła uczestników z Polski, USA, Holandii, Niemiec, Wielkiej Brytanii, Estonii, Ukrainy, Rosji, Nigerii, Indii, Pakistanu, Tunezji oraz Indonezji. Zawodnicy reprezentowali między innymi Uniwersytet Warszawski, Uniwersytet Jagielloński, Carnegie Mellon University, czy National University of Lviv. Do rywalizacji stanęli również przedstawiciele takich firm jak Google, InsERT, czy Flytronic.

Organizatorem Deadline24 jest firma Future Processing, która działa na globalnym rynku oprogramowania od 2000 roku, tworząc systemy informatyczne dedykowane między innymi branży przemysłu, mediów elektronicznych, opieki medycznej, sektora finansowego oraz transportu. Firma jest Certyfikowanym Partnerem Microsoftu i posiada tytuły „Independent Software Vendor” oraz „Software Development” na poziomie Gold.

Aby być na bieżąco zapraszamy do śledzenia naszego fanpage na Facebooku https://www.facebook.com/Deadline24pl.

Źródło: inf. prasowa Future Processing

Nie mam słów i jestem zażenowany poziomem tzw. webdeveloperów portujących pluginy pod Angulara. Zdecydowana większość tego syfu to wrappery na ścierwo pisane pod jQuery. Tak, ścierwo, bo ta biblioteka sama w sobie jest jak lep na muchy, który przez swoją tandetną prostotę przyciąga tabuny amatorów przykładających swoje uszczerbione i ufajdane cegiełki do dziurawej budowli wznoszonej od lat przez nadęte i oderwane od rzeczywistości community open source. I mimo, że są perły pod jQuery, to tworząc soft pod Angulara używanie jQuery jest nadmiarem, naroślą, wrzodem na dupie i opuchlizną dręczącą i tak nie najlżejszy framework.

Jedyny sens jest portować tak, aby nie miały zależności od jQuery czy innych wynalazków tworzonych jako dodatek do HTML-a. Dlatego ciśną mi się na klawiaturę słowa: ludzie, przestańcie do cholery robić syf - albo robicie coś porządnie, albo nie róbcie tego wcale. Później mamy taki sektor IT, jaki sobie tworzymy. Poczytajta też Stack Overflow w tym temacie.

Czołem.