Kilka koncepcji związanych z konfliktem REST w mojej głowie, gdy próbuję go zaimplementować.
Mam system API zaplecza REST, który obsługuje logikę biznesową, oraz aplikację internetową, która udostępnia interfejs użytkownika. Z różnych zasobów na temat REST (szczególnie REST w praktyce: Hypermedia i architektura systemów ) wiem, że nie powinienem ujawniać surowych identyfikatorów moich bytów, ale raczej zwracać hiperłącza rel="self".
Rozważ przykład. Interfejs API REST ma zasób, który zwraca osobę:
<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>
Problem pojawia się w przypadku aplikacji internetowej. Załóżmy, że zwraca stronę zawierającą hiperłącze do przeglądarek:
<body class="person">
<p>
<a href="http://my.web.app/pet/???????" />
</p>
</body>
Co powinienem umieścić w hrefatrybucie? Jak zachować adres URL encji API w aplikacji internetowej, aby móc uzyskać encję, gdy użytkownik otworzy stronę docelową?
Wymagania wydają się sprzeczne:
- Hiperłącze
hrefpowinno prowadzić do aplikacji internetowej, ponieważ jest to system obsługujący interfejs użytkownika hrefPowinien mieć jakiś identyfikator podmiotu ponieważ aplikacja internetowa musi być w stanie zająć się podmiot, gdy strona docelowa otwiera- Ta aplikacja mówi, że aplikacja internetowa nie powinna analizować / konstruować adresów URL REST, ponieważ nie jest to REST-ful
Identyfikatory URI powinny być nieprzejrzyste dla konsumentów. Tylko wydawca identyfikatora URI wie, jak go zinterpretować i odwzorować na zasób.
Dlatego nie mogę po prostu pobrać 1234adresu URL odpowiedzi interfejsu API, ponieważ jako klient RESTful powinienem traktować go tak, jakby był czymś podobnym http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. Z drugiej strony muszę podać adres URL, który prowadzi do mojej aplikacji internetowej i wystarczy, aby aplikacja w jakiś sposób przywróciła oryginalny adres URL interfejsu API i użyła tego adresu URL, aby uzyskać dostęp do zasobów interfejsu API.
Najprostszym sposobem jest prawdopodobnie użycie adresów URL API zasobów jako ich identyfikatorów ciągów. Ale adresy URL stron internetowych http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234są brzydkie.
Wszystko wydaje się dość łatwe w przypadku aplikacji komputerowej lub jednostronicowej aplikacji javascript. Ponieważ żyją nieprzerwanie, mogą po prostu przechowywać adresy URL w pamięci wraz z obiektami usług przez cały okres użytkowania aplikacji i używać ich w razie potrzeby.
Dzięki aplikacji internetowej mogę sobie wyobrazić kilka podejść, ale wszystkie wydają się dziwne:
- Zamień hosta na adresy URL API i zachowaj tylko wynik. Ogromną wadą jest to, że wymaga aplikacji internetowej do obsługi dowolnego adresu URL generowanego przez interfejs API, co oznacza monstrualne połączenie. Co więcej, nie jest to ponownie RESTful, ponieważ moja aplikacja internetowa zaczyna interpretować adresy URL.
- Ujawnij nieprzetworzone identyfikatory w interfejsie API REST wraz z łączami, użyj ich do zbudowania adresów URL aplikacji sieci Web, a następnie użyj identyfikatorów na serwerze aplikacji sieci Web, aby znaleźć wymagane zasoby w interfejsie API. Jest to lepsze, ale wpłynie to na wydajność serwera aplikacji WWW, ponieważ aplikacja internetowa będzie musiała przejść przez nawigację usługi REST, wydając ciąg żądań get-by-id jakiejkolwiek formy, aby obsłużyć dowolne żądanie z przeglądarki. W przypadku nieco zagnieżdżonego zasobu może to być kosztowne.
- Przechowuj wszystkie
selfadresy URL zwrócone przez interfejs API w trwałym mapowaniu (DB?) Na serwerze aplikacji WWW. Wygeneruj dla nich kilka identyfikatorów, użyj ich do zbudowania adresów URL stron aplikacji sieci Web i uzyskania adresów URL zasobów usługi REST. Tj. Trzymamhttp://my.rest.api/pet/678adres URL gdzieś z nowym kluczem, powiedzmy3, i generuję adres URL strony internetowej jakohttp://my.web.app/pet/3. Wygląda to jak pewnego rodzaju implementacja pamięci podręcznej HTTP. Nie wiem dlaczego, ale wydaje mi się to dziwne.
Czy to wszystko oznacza, że interfejsy API RESTful nie mogą służyć jako zaplecze dla aplikacji internetowych?