· kaynak dev.to (home feed)
Ücretsiz Trademarx API, 3,3 milyon Hint trademark kaydını geliştiricilerin erişimine açıyor
Bir fikri mülkiyet hukuku bürosu, Hindistan Trade Marks Registry'den kazıdığı 3,3 milyondan fazla kaydı Trademarx adlı ücretsiz, yalnızca okunabilir bir public API olarak paketledi; API basit key doğrulaması ve sıkı rate limitleri kullanıyor.

Ne piyasaya çıktı
Bir fikri mülkiyet hukuku bürosu, Hindistan Trade Marks Registry'den kazıdığı veriyi ücretsiz bir API olarak kamuya açtı. dev.to'da yayınlanan bir yazıya göre Trademarx'ın arkasındaki veri seti, Trade Marks Journal'ın 1703. sayısına kadar uzanan 3,3 milyondan fazla trademark kaydını kapsıyor; derginin kendisi şu anda 2200'lü sayılarda.
Proje iç araç olarak başlamış. Büronun registry'de programatik arama yapması gerekiyordu, veriyi kazıdılar ve daha sonra bir marka temizlik (brand-clearance) aracı geliştiren biri verilerin bir servis olarak sunulup sunulmadığını sorunca bir API çıkardılar. Sunulmuyordu, o yüzden kendileri bir tane inşa ettiler.
API nasıl çalışıyor
Servis tam olarak iki adet yalnızca okunabilir GET endpoint'i sunuyor: biri trademark'ları isim ve sınıfa göre arıyor, diğeri numarasıyla bir Trade Marks Journal sayısının tamamını döndürüyor. Yanıtlar sarmalayıcı nesne içermeyen düz JSON dizileri; sayfalama üst verisi ise yanıt gövdesinde değil header'larda taşıyor — toplam sayı değeri ve sonraki ile son sayfayı işaret eden Link header'ları.
Doğrulama, süresi dolmayan ve OAuth akışı içermeyen tek bir API-key header'ından oluşuyor. Yazıya göre key'ler onay kuyruğu olmadan anında veriliyor ve public endpoint'lerde açık CORS var, yani doğrudan tarayıcı JavaScript'inden çağrılabiliyorlar — yine de yazarlar bir key'i client tarafı kodda göndermeme konusunda uyarıyor ve gerçek kullanımlar için kendi backend'iniz üzerinden proxy'lemeyi öneriyor. OpenAPI 3.1 spesifikasyonu canlı controller'lardan üretiliyor; yazarlar bunun spesifikasyonun uygulamayla eşzamansız kalmasını engellediğini söylüyor.
Geliştiricilerin bilmesi gereken veri uyarıları
Yalnızca üç alanın null olmadığı garanti: başvuru numarası, trademark sınıfı ve kanonik bir URL. İsim alanı, kayıtların önemli bir kısmında eksik — çünkü device ve figüratif markaların kelime unsuru yok — bu yüzden yazı, kayıtları isme göre değil başvuru numarasına göre anahtarlamanızı öneriyor.
Trademark durum alanı kayıtların çoğunda null — bunun nedeni verinin atılmış olması değil, registry'nin bir durum yayınlamamış olması. Durumun mevcut olduğu yerlerde ise sabit bir sözlüğü olmayan serbest metin; Registered, Abandoned ve Formalities Chk Pass gibi değerleri kapsıyor. Kullanıcılara tam dize eşleşmesi yerine gevşek eşleştirme yapmaları ve null durumu bir okuyucunun hukuki bir gerçek sanabileceği her yerde "Bilinmiyor" olarak göstermemeleri söyleniyor.
Limitler ve tek şart
Kullanım, endpoint grubu başına günde 200 istekle sınırlı. Sayfa boyutu, daha fazlasını isteseniz bile sabit olarak 20; sorgular en fazla 50 sayfayı kapsayabiliyor ve erişilebilen en derin kayıt 1.000 — bu tavana çarpmamanın önerilen çözümü daha ileri sayfalara gitmek değil sorguyu daraltmak. Bulk export yok ve yazma erişimi yok; yazarlar bunu bilinçli bir tercih olarak tanımlıyor: bulk dump'lar da sunan ücretsiz bir katman, başkasının veri seti işini sübvanse etmek olur. Bulk ihtiyaçları e-posta yoluyla karşılanıyor.
API, kayıtlı alan adında görünür bir atıf bağlantısı karşılığında ücretsiz. Uyum haftalık olarak kontrol ediliyor ve askıya almadan önce bir uyarı veriliyor. Ayrıca her yanıtta, o kaydın kanonik sayfasını işaret eden bir URL alanı var; bu, sonuç başına atıf bağlantısı olarak da kullanılabilir.
Registry'yi kazımak gerçekte ne gerektirdi
dev.to'daki yazının büyük kısmı registry'nin kendisiyle ilgili. Journal dosyaları, sayının kabaca ne zaman yayınlandığına bağlı olarak iki farklı dosya adlandırma kuralını izliyor; belgelenmiş bir sınır ve changelog yok. Yanlış tahmin etmek, 404 yerine HTML hata sayfalı bir 500 üretiyor; bu da content type kontrolü yapmayan bir parser'ı sessizce bozabiliyor.
Sessiz bir kesme hatası başlangıçta crawler'ın eşzamanlılık mantığındaki bir kilitlenme gibi görünüyordu. Gerçek neden, HTTP client'ın yanıt gövdelerini 2MB'ta sınırlamasıydı; bazı sayıların listeleme sayfaları ise yaklaşık 2,3MB gerektiriyordu — hata yok, çökme yok, yalnızca biri elle sayıları portal ile karşılaştırana kadar var olan satırlardan daha azı.
Registry'nin canlı durum sorgusunu koruyan captcha, frontend'in gerçekte ne çağırdığına bakınca, headless browser veya görüntü çözme gerektirmeyen düz bir JSON istek-yanıtı çıktı.
Yazarların daha geniş çıkarımı şu: devlet portalları genellikle gürültülü biçimde hata vermiyor. Verilerin çoğunu veriyorlar ve geri kalan eksik kısmı keşfetmeyi size bırakıyorlar.
Neden önemli
Hint trademark kayıtlarına büyük ölçüde yalnızca otomasyona direnen bir portal üzerinden erişilebiliyordu; bu da programatik marka kontrollerini, izleme servislerini ve fikri mülkiyet araştırmalarını kırılgan bir scraper inşa etmeden (ve ayakta tutmadan) pratik olmaktan çıkarıyordu. Trademarx bu engeli küçük ölçekli kullanım senaryoları için kaldırıyor; API tasarımı — header tabanlı sayfalama, garanti anahtar alanlar, otomatik üretilen spesifikasyon — altta yatan verinin nerede tutarsız olduğuna dair zorla kazanılan bilgiyi yansıtıyor.
Sınırlamalar onun nişini tanımlıyor. Günlük üst sınırlar, 1.000 kayıtlık derinlik tavanı, bulk export olmaması ve atıf şartı, onu veri seti yeniden paketleme yerine entegrasyonlar ve sorgular için konumlandırıyor; null ve serbest metin durum değerlerinin yaygınlığı ise onu otoriter bir hukuki kayıt değil, bir araştırma yardımcısı yapıyor. Tüm ayrıntılar projenin kendi dev.to duyurusundan geliyor; yani veri setinin eksiksizliği ve davranışı, bağımsız olarak doğrulanmış değil, yazarları tarafından iddia edildiği şekliyle.
- #api
- #trademarks
- #open-data
- #india
- #developer-tools