Google Health API'de Veri Yönetimi

Google Health API'deki verilerle çalışmak, temel olarak buluttaki Google Health API veri deposu ile kendi uygulamanız veya arka uç veri deponuz arasında veri senkronizasyonu yapma döngüsüdür. Ancak bu döngü, çeşitli faktörlere bağlı olarak farklı biçimlerde olabilir:

• Google Health API'ye veri yazıyor musunuz? Sadece okuma mı yapıyorsunuz? Yoksa ikisini de mi yapıyorsunuz?
• Veri deponuz uygulamada veya cihazda yerel olarak mı bulunuyor? Yoksa kendi bulutunuzda mı?
• Google Health API verilerini kullanıcının uygulaması ile giyilebilir cihaz arasında senkronize etmeniz gerekiyor mu? Cihazları ne sıklıkta senkronize ediyorsunuz?
• Ne tür verilerle çalışıyorsunuz? Temel sayıları mı? Ölçü birimleri? Farklı örnekleme hızlarına sahip seriler mi var?
• Uygulamanız arka plandayken veri okumayı planlıyor musunuz?
• Uygulamanız kullanıcı izinlerini almadan önce kaydedilen geçmiş verilerle çalışmayı planlıyor musunuz?

Tüm bu işlemlerin nasıl birlikte çalıştığını anlamak için Google Health API senkronizasyon yaşam döngüsüne göz atın. Bu yaşam döngüsünün iki sürümü vardır: standart (okuma ve yazma) ve salt okunur.

Standart senkronizasyon yaşam döngüsü

Şekil 1: Google Health API'deki standart senkronizasyon yaşam döngüsü

Google Health API ile entegrasyon, verilerin bir uygulamaya veya arka uç veri deposuna kopyalanması anlamına gelir. Bu dokümanda kolaylık sağlamak için bu veri deposuna geliştirici veri deposu diyeceğiz.

Buradaki "kopyalama", Google Health API'den okuma (geliştirici veri deposuna kopyalama) veya Google Health API'ye yazma (Google Health API'ye kopyalama) gibi ayrı bir etkinliğin yerini alabilir. Bu işlemlerin belirli bir sırada tekrar tekrar yapılmasına senkronizasyon yaşam döngüsü denir.

Şekil 1, daha önce bahsedilen faktörlerden bağımsız olarak okuma ve yazma işlemlerini içeren standart senkronizasyon yaşam döngüsünü gösterir.

Yazma

1. Yazmak için yeni veriler hazırlama: Verileri harici bir cihazdan veya uygulamadan aktarın ve veri noktalarını Google Health API veri türleriyle uyumlu JSON gösterimlerine biçimlendirin. Yazma işlemleri için özel istemci tarafından atanan kimliklerin şu anda Health API'de desteklenmediğini unutmayın. Bu tür kimlikler POST içinde sağlanabilir ancak yoksayılır.
2. Kayıtları ekleme/güncelleme: REST uç noktalarını kullanarak Google Health API'ye veri noktaları gönderin. Kayıt oluşturmak için POST, mevcut kayıtları eklemek ve güncellemek için PATCH simgesini kullanın. PATCH işlemi için gereken kimlikler, önceki bir POST işleminden (önceki bir döngüdeki sonraki adım) alınmış olmalıdır.
3. Döndürülen kaynak kimliklerini işleme: Sunucu tarafından oluşturulan kimlikleri kullanırken gelecekteki güncellemeleri (PATCH) veya silme işlemlerini (DELETE) etkinleştirmek için sunucu tarafından döndürülen kaynağı name veya kimliği geliştirici veri deponuzda ayıklayın ve kalıcı hale getirin. İki tür hakkında daha fazla bilgi için Tanımlama stratejileri bölümüne bakın.

Okuma

1. Kayıtları okuma: REST uç noktalarını (GET ile filter sorgu parametreleri ve pageToken sayfalama veya rollUp ve dailyRollUp gibi toplama uç noktaları) kullanarak Google Health API'deki yeni verileri ve mevcut verilerdeki değişiklikleri getirin ya da Webhook aboneliklerini (projects.subscribers) kullanarak anlık bildirimler alın. Bildirim yalnızca yeni verilerin mevcut olduğunu gösterir, gerçek verilerin ne olduğunu göstermez.
2. Geliştirici veri deposunu mutabakat etme: Yeni ve güncellenmiş verileri geliştirici veri deponuzla mutabakat edin.

Bu döngü daha sonra harici cihazların veya uygulamaların özel ihtiyaçlarına göre uygun aralıklarla tekrarlanır. Bu genellikle kendi veri deponuz ile Google Health API arasında verileri senkronize etmek için önerdiğimiz sıradır.

Tanımlama stratejileri

Google Health API'ye veri yazmayı planlıyorsanız Google Health API'lerle entegrasyonunuzu oluşturmadan önce veri noktaları (temel veri birimi) oluştururken bir kaynak tanımlama stratejisi seçmeniz gerekir.

Yazma işlemleri için istemci tarafından atanan kimlikler şu anda Health API'de desteklenmemektedir. Bu tür kimlikler POST içinde sağlanabilir ancak yoksayılır. Bu seçenekle ilgili ayrıntılar, bilgilendirme amacıyla burada verilmiştir.

1. Sunucu Tarafından Oluşturulan Kimlikler (varsayılan seçenek): İstemci, verileri kimlik olmadan gönderir ve Google Health API arka ucu, benzersiz bir sistem tanımlayıcısı oluşturup döndürür.
2. İstemci Tarafından Atanan Özel Kimlikler (AIP-133 uyarınca, henüz desteklenmemektedir): İstemci uygulaması, benzersiz bir tanımlayıcı (örneğin, UUID veya yerel veritabanı birincil anahtarı) oluşturur ve oluşturma sırasında kaynak yolunda sağlar.

Aşağıdaki tabloda, entegrasyonunuz için doğru yaklaşımı seçmenize yardımcı olmak amacıyla her iki tanımlama stratejisi karşılaştırılmaktadır:

Özellik	Sunucu Tarafından Oluşturulan Kimlikler	Müşteri Tarafından Atanan Özel Kimlikler
Kimlik Oluşturma	Sunucu, yürütme sırasında rastgele sistem kimliği oluşturur.POST	İstemci, yazma işleminden önce yerel olarak sabit bir kimlik (UUID v4 / dahili PK) oluşturur.
Kaynak Yolu	.../dataPoints/{server_id} (yanıtta döndürüldü)	.../dataPoints/{custom_id}
Yerel Yazma Sonrası Adımı	Zorunlu. Gelecekteki güncellemeleri/silme işlemlerini etkinleştirmek için döndürülen server_id, yerel veritabanında saklanmalıdır.	Yok. Uygulama zaten kimliğin sahibi.
Kimlik Eşleme Tablosu	Zorunlu. Müşteri, iki yönlü bir eşleme sürdürmelidir (local_id ↔ server_id).	Gerekli değildir. İstemci, kendi birincil anahtarını doğrudan kullanır.
Yeniden Deneme Davranışı (Zayıf Ağ)	Yinelenen Öğeler Riski. Zaman aşımına uğrayan bir POST işlemi yeniden denendiğinde yeni bir sunucu kimliğine sahip yinelenen bir kayıt oluşturulur.	Güvenli ve Idempotent. Aynı custom_id ile POST yeniden deneme, yinelenen oluşturmayı engeller (409 ALREADY_EXISTS döndürür).
Çevrimdışı Senkronizasyon Desteği	Sınırlı. Resmi kaynak kimliklerini almadan önce sunucu yanıtı beklenmelidir.	Tam Öğeler, kararlı kimliklerle çevrimdışı olarak oluşturulabilir ve değiştirilebilir. Ardından, yeniden bağlandığınızda sorunsuz bir şekilde senkronize edilebilir.
Biçim Kısıtlamaları	Tamamen sunucu tarafından işlenir.	^[a-z0-9-]{4,63}$ (4-63 küçük harf, alfanümerik karakter ve tire) olmalıdır.
Ne zaman seçilir?	Aşağıdaki durumlarda sunucu tarafından oluşturulan kimlikleri seçin: Uygulamanız yalnızca yazma / ekleme işlemine izin veriyor (ör. daha sonra güncellenmeyen veya silinmeyen telemetri ya da adım sayısı gönderme). Uygulamanız, tek tek veri noktalarının yerel ve kalıcı bir veritabanını tutmuyor. Dize doğrulama kısıtlamalarını (ör. 4-63 karakterleri) yönetmeden basitliği tercih ediyorsunuz.	Aşağıdaki durumlarda özel kimlikleri seçin: Cihazlar arasında sağlık kayıtlarını okuyan, yazan ve güncelleyen iki yönlü bir senkronizasyon uygulaması işletiyorsanız. Uygulamanızda, yerel birincil anahtarlara sahip kayıtları depolayan yerel bir veritabanı (ör. Room veya SQLite) var. Kullanıcılarınız verileri çevrimdışı olarak veya güvenli yeniden denemelerin gerekli olduğu aralıklı mobil bağlantılar üzerinden kaydediyor. Arka uç veritabanınız ile API arasındaki kimlik eşleme tablolarını ortadan kaldırmak istiyorsunuz.

Salt okunur senkronizasyon yaşam döngüsü

Şekil 2: Google Health API'de salt okunur senkronizasyon yaşam döngüsü

Yalnızca Google Health API'den okuma yapmayı amaçlayan bir uygulama, verileri geliştirici veri deposuna kopyalamalı ve yaşam döngüsünün mutabakat kısmını yönetmelidir.

Okuma bölümünde ele alınan görevler burada da geçerlidir.

Şekil 2'de salt okunur yaşam döngüsü gösterilmektedir.