Genderize.io - Et gratis API til kønsbestemmelse af fornavn

Hej Aminoer

Jeg startede for et par uger siden et lille lærings-projekt. Kort sagt var der flere teknikker omkring API opbygning jeg ville afprøve og det er jo altid sjovest at have et egentligt projekt at arbejde på.

Det tog pludselig fart da API'et kom online og det gav lysten til at gøre det til et egentligt produkt. Efterfølgende har jeg hastet et par updates igennem for at forbedre svar kvaliteten. 

Genderize.io modtager et eller flere fornavne på endpointet og returnere et probabilistisk gæt på kønnet. Svarene er baseret på et stort og voksende datasæt af brugerprofiler fra diverse sociale netværk. Udover fornavn og køn indeholder datasættet også en lande kode og en sprog kode for hvert entry, hvilket giver muligheden for at tilføje lokale filtrer til hvert request. Man har altså nu muligheden for at kønssegmentere bruger/mail-lister etc. til marketing, analyse eller lignende.

API'et er gratis at benytte og der er indtil videre ingen rate limits.

I kan lave en simpel test med følgende URL: http://api.genderize.io?name=peter 

Jeg håber der sidder nogen nørder som kan få bruge det til noget :)

Al feedback er velkommen. 

Et tip ville være at ændre måden url strukturen virker på, evt tag et kig på måden du ofte designer REST api'er

Et eksempel kunne være:

istedet for http://api.genderize.io?name=peter kunne det være http://api.genderize.io/name/peter og hvis du udvider til flere navne kunne det være http://api.genderize.io/names/peter,john,simon eller http://api.genderize.io/names/peter+john+simon/country_id/US whatever - der er mange måder man kan designe det på. Men det er self, op til hver person hvad de syntes er simpler :D

Casper Fischer:

Jeg synes det er lidt sørgeligt at dit eget navn ikke kan kønsbestemmes :)

{"name":"casper","gender":null}

Hørt hørt :) Datasættet er ikke så stort endnu, men jeg modtager ca. 10.000 profiler i døgnet, så mon ikke snart den fanger en Casper :)

Lucas - Hosting4Real:

Et tip ville være at ændre måden url strukturen virker på, evt tag et kig på måden du ofte designer REST api'er

Et eksempel kunne være:

istedet for http://api.genderize.io?name=peter kunne det være http://api.genderize.io/name/peter og hvis du udvider til flere navne kunne det være http://api.genderize.io/names/peter,john,simon eller http://api.genderize.io/names/peter+john+simon/country_id/US whatever - der er mange måder man kan designe det på. Men det er self, op til hver person hvad de syntes er simpler :D

Tak for feedback'en. Jeg overvejede at designe mine endpoints således, men jeg syntes i sidste ende det bliver lidt overflødigt. For at holde RESTful standarder ville man nok benytte én URL, names, både til forespørgsler på enkelt navne og flere navne af gangen. Én resource, ét endpoint. Så mine URL'er ville hedde api.genderize.io/names?blabla til begge methods. Og hvorfor så ikke bare api.genderize.io?blabla? :) 

Lucas - Hosting4Real:

Kommer an på hvordan du ser på designet nu, og i fremtiden, jeg siger heller ikke min løsning er den rigtige - var ren feedback - jeg ved ikke hvad fremtiden med API'et er, men internt hvor jeg arbejder, har vi flere eksempler på hvor man ville adskille med single eller multi value requests. Kan f.eks, være mængden af data du giver i response til brugeren.

Men hvis du ser begge ting som samme resource, så kunne man lave http://api.genderize.io/peter  eller ?peter ja.

Jeg syntes faktisk at http://api.genderize.io/peter er pænest og man kan nok også blive enige om at det er den nemmeste syntax. Den eneste grund til at jeg holdte mig fra det var fordi at man ved flere navne så ville skulle sende en string ala http://api.genderize.io/peter+lois+stevie som jeg ville skulle manipulere fremfor at man kunne taste dem som hver sit "parameter". Men det er sku noget pænere, måske jeg skulle lukke op for begge dele :)

I forhold til om man bruger flere endpoints per resource så påpegede jeg blot at man efter RESTful standarder ville benytte ét endpoint per resource. Jeg mangler dog stadig at støde på et 100% RESTful API. Det er vidst stadig bare en våd drøm for de fleste udviklere :D

Casper Strømgren:

Lucas - Hosting4Real:

Kommer an på hvordan du ser på designet nu, og i fremtiden, jeg siger heller ikke min løsning er den rigtige - var ren feedback - jeg ved ikke hvad fremtiden med API'et er, men internt hvor jeg arbejder, har vi flere eksempler på hvor man ville adskille med single eller multi value requests. Kan f.eks, være mængden af data du giver i response til brugeren.

Men hvis du ser begge ting som samme resource, så kunne man lave http://api.genderize.io/peter  eller ?peter ja.

Jeg syntes faktisk at http://api.genderize.io/peter er pænest og man kan nok også blive enige om at det er den nemmeste syntax. Den eneste grund til at jeg holdte mig fra det var fordi at man ved flere navne så ville skulle sende en string ala http://api.genderize.io/peter+lois+stevie som jeg ville skulle manipulere fremfor at man kunne taste dem som hver sit "parameter". Men det er sku noget pænere, måske jeg skulle lukke op for begge dele :)

I forhold til om man bruger flere endpoints per resource så påpegede jeg blot at man efter RESTful standarder ville benytte ét endpoint per resource. Jeg mangler dog stadig at støde på et 100% RESTful API. Det er vidst stadig bare en våd drøm for de fleste udviklere :D

Vi har et internt API, der er 99% RESTful ;)

Men igen, ja, restful standard = ét endpoint per resource, men spørgsmålet, er jo så hvad du ser som forskellige resources, /name, og /names kan sagtens være 2 forskellige resources, kommer an på funktionerne i API'et i sidste ende