RESTful composizione / inclusione di altre risorse

Question

RESTful composizione / inclusione di altre risorse

#1 da (2 voti)

2

Ho alcune risorse HTTP e mi chiedo se includere i modelli di uno nell'altro sia accettabile o se esiste un metodo più pulito.

In questo esempio, abbiamo un sacco di risorse "news" e gli utenti possono iscriversi tramite una risorsa chiamata "subscription":

==>/news-items/{id}/
{
    "id": 987,
    "url": "http://example.com/foo/bar",
    "title": "Wow! A Headline",
}

E

==> /users/{user-id}/subscriptions/
[
    {
         "id" : 123
         "keywords": "Mr Celebrity"
    },
    ...
]

E poi l'endpoint che include i modelli di entrambe le risorse ...

==> /users/{user-id}/my-news/
[
    {
        "id": 987,
        "url": "http://example.com/foo/bar",
        "title": "Wow! A Headline",
        "matched_by": [
            {
                "id": 123,
                "keywords": "Wow",
            },
            ...
        ]
    },
    ...
]

Il caso d'uso è abbastanza autoesplicativo per questo: un feed di notizie con 'abbinato da' Mr Celebrity '' accanto ad esso. È un po 'strano avere un endpoint che consiste solo di modelli nidificati / compositi di altri endpoint ... Questa pratica è accettabile o problematica?

L'endpoint sarà di sola lettura e le altre opzioni sembrano essere:

Stile HATEOAS: "matched_by" e le notizie sono URL che puntano a una notizia e un abbonamento. Richiederebbe più richieste HTTP.
Una sorta di risposta multi-payload con un carico utile primario HATEOAS e un carico utile "correlato" delle risorse di riferimento. Non visto prima.
??? qualche altra opzione?

Se il mio approccio è valido, ottimo, ma voglio sapere cosa farebbero gli altri se c'è un'alternativa migliore.

Grazie:)

design-patterns rest http

posta Aiden Bell 05.05.2014 - 23:53

fonte

1 risposta

Leggi altre domande sui tag design-patterns rest http

Accesso a un server remoto dall'applicazione desktop Fornitura di immagini da google cloud ridimensionate a 300x200

score 2 · Accepted Answer

A feed of news with 'matched by "Mr Celebrity"' next to it. It feels a bit weird to have an endpoint that consists only of nested/composite models from other endpoints ... Is this acceptable practice or problematic?

Avere rappresentazioni di risorse incorporate è perfettamente valido, dal momento che descrivi un grafico di risorse in cui ogni risorsa può essere connessa a un'altra risorsa ...

Se fossi in te controllerei alcuni tipi di ipermedia standard invece di crearne uno proprio. Ad esempio: JSON-LD , HAL , Collection + JSON , ecc ...

HATEOAS-style: "matched_by" and the news item are URLs pointing to a news item and subscription. Would require more HTTP requests.

HATEOAS parla dell'uso di collegamenti ipertestuali, non di semplici URL. Non confondere questi termini ... Un collegamento ipertestuale consiste di almeno un metodo HTTP ( calling an operation ) e un URL ( on a resource ). Per REST devi aggiungere alcuni metadati ad esso, ad esempio relazione di collegamento o Hydra: operazione (se preferisci RDF).

Solo un esempio HAL di copia-incolla da uno dei siti collegati:

{
    "_links": {
        "self": { "href": "https://api.example.com/player/1234567890/friends" },
        "next": { "href": "https://api.example.com/player/1234567890/friends?page=2" }
    },
    "size": "2",
    "_embedded": { 
        "player": [
            { 
                "_links": { 
                    "self": { "href": "https://api.example.com/player/1895638109" },
                    "friends": { "href": "https://api.example.com/player/1895638109/friends" }
                },
                "playerId": "1895638109",
                "name": "Sheldon Dong",
                "alternateName": "sdong",
                "image": "https://api.example.com/player/1895638109/avatar.png"
            },
            { 
                "_links": { 
                    "self": { "href": "https://api.example.com/player/8371023509" },
                    "friends": { "href": "https://api.example.com/player/8371023509/friends" }
                },
                "playerId": "8371023509",
                "name": "Martin Liu",
                "alternateName": "mliu",
                "image": "https://api.example.com/player/8371023509/avatar.png"
            }
        ]
    }
}

Come puoi vedere, definisce una proprietà size e due player s incorporate per una risorsa di raccolta. Ogni rappresentazione contiene collegamenti. È possibile trovare l'identificatore di risorsa principale (URI) sotto i collegamenti che presentano la relazione di collegamento self . Questo è solo un esempio. La maggior parte dei tipi di ipermedia generici utilizza approcci simili. Btw. questa è solo la parte GET della storia. (HAL non supporta i collegamenti POST, PUT, DELETE, devi usare un'estensione per descriverli.)

Comprensione di una soluzione migliore, come RDF con JSON-LD e Hydra sarebbero una storia più lunga ...