Diversi concetti legati al conflitto REST nella mia testa quando provo a implementarlo.
Ho un sistema API back-end REST completo che detiene la logica aziendale e un'applicazione Web che fornisce l'interfaccia utente. Da varie risorse su REST (in particolare, REST in Practice: Hypermedia and Systems Architecture ) so che non dovrei esporre identificatori grezzi delle mie entità, ma piuttosto restituire hyperlink con rel="self".
Considera l'esempio. L'API REST ha una risorsa che restituisce una persona:
<Person>
<Links>
<Link rel="self" href="http://my.rest.api/api/person/1234"/>
</Links>
<Pets>
<Link rel="pet" href="http://my.rest.api/api/pet/678"/>
</Pets>
</Person>
Il problema sorge con l'applicazione Web. Supponiamo che ritorni una pagina che contiene un collegamento ipertestuale ai browser:
<body class="person">
<p>
<a href="http://my.web.app/pet/???????" />
</p>
</body>
Cosa devo inserire hrefnell'attributo? Come posso mantenere l'URL dell'entità API nell'applicazione Web per poter ottenere l'entità quando un utente apre la pagina di destinazione?
I requisiti sembrano contrastanti:
- Il collegamento ipertestuale
hrefdovrebbe portare all'applicazione Web perché è il sistema che ospita l'interfaccia utente - L'
hrefdovrebbe avere qualche id dell'entità in quanto l'applicazione web deve essere in grado di affrontare l'entità in cui la pagina di destinazione si apre - L'app Web non dovrebbe analizzare / costruire URL REST perché non è REST, dice il libro citato
Gli URI dovrebbero essere opachi per i consumatori. Solo l'emittente dell'URI sa come interpretarlo e mapparlo su una risorsa.
Quindi, non posso semplicemente prendere 1234dall'URL di risposta dell'API perché come client RESTful dovrei trattarlo come se fosse qualcosa del genere http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. D'altra parte, devo fornire un URL che porta alla mia app Web ed è sufficiente affinché l'app ripristini in qualche modo l'URL originale dell'API e utilizzi tale URL per accedere alle risorse API.
Il modo più semplice consiste probabilmente nell'utilizzare gli URL API delle risorse come identificatori di stringhe. Ma gli URL delle pagine web http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234sono brutti.
Sembra tutto abbastanza semplice per un'app desktop o un'app javascript a pagina singola. Dal momento che vivono continuamente, possono semplicemente mantenere gli URL in memoria insieme agli oggetti di servizio per la durata dell'applicazione e usarli quando necessario.
Con un'app Web posso immaginare diversi approcci, ma sembrano tutti strani:
- Sostituisci l'host negli URL API e mantieni solo il risultato. L'enorme svantaggio è che richiede all'applicazione web di gestire qualsiasi URL generato dall'API, il che significa accoppiamento mostruoso. Inoltre, non è di nuovo RESTful, perché la mia app Web inizia a interpretare gli URL.
- Esporre gli ID non elaborati nell'API REST insieme ai collegamenti, utilizzarli per creare gli URL delle app Web, quindi utilizzare gli ID sul server delle app Web per trovare le risorse richieste nell'API. Questo è meglio, ma influirà sulle prestazioni del server delle app Web perché l'app Web dovrà passare attraverso la navigazione del servizio REST emettendo una catena di richieste get-by-id di qualche modulo per gestire qualsiasi richiesta da un browser. Per una risorsa un po 'nidificata questo potrebbe essere costoso.
- Archivia tutti gli
selfURL restituiti dall'API in una mappatura persistente (DB?) Sul server delle app Web. Genera alcuni ID per loro, usa gli ID per creare gli URL della pagina dell'app Web e ottenere gli URL delle risorse del servizio REST. Cioè tengo ilhttp://my.rest.api/pet/678URL da qualche parte con una nuova chiave, diciamo3, e generare l'URL della pagina web comehttp://my.web.app/pet/3. Sembra un'implementazione della cache HTTP di qualche tipo. Non so perché, ma mi sembra strano.
O Significa tutto che le API RESTful non possono fungere da backend per le applicazioni Web?