Gli ID delle risorse REST sono numeri interi o stringhe?

Question

Gli ID delle risorse REST sono numeri interi o stringhe?

#1 da (5 voti)
#2 da (0 voti)

0

Progettazione di una piccola API sul lato / per divertimento / per esperienza. Un problema che ho incontrato è il routing URI. Il problema è:

GET /users/{id}   // Get user data
GET /users/availability  // Get all users' availability

Entrambe le mappe si riferiscono allo stesso controller @ metodo basato su quale viene prima nel mio file Routes.php.

La funzione che sto utilizzando per trovare effettivamente i percorsi è la seguente:

public function find($request)
{
    foreach($this->collection[$request->method] as $route)
    {
        $pattern = "'^".preg_replace('/{[a-zA-Z0-9\_\-]+}/', '([a-zA-Z0-9\-\_]+)', $route->uri)."$'";

        if (preg_match($pattern, $request->resource, $matches)) 
        {
            array_shift($matches);
            $route_package = ['route' => $route, 'params' => $matches];

            return $route_package;
        }
    }

    return null;
}

Non riesco davvero a vedere un RegExp in grado di risolvere questo problema. L'unica idea che avevo era di limitare gli ID delle risorse ai numeri interi ma poi non posso usare le date come l'ID della risorsa come nel caso di:

GET /calendar/2017-07-11          // Returns data about 2017-07-11

php rest

posta keelerjr12 12.07.2017 - 01:36

fonte

2 risposte

0

Gli ID risorse nei servizi HTTP RESTful vengono solitamente considerati stringhe, sebbene per la tua API puoi posizionare le restrizioni come meglio credi.

Tuttavia, ci sono altri modi per gestire e presentare gli indirizzi della tua API, per evitare scontri nello spazio dei nomi. Sto dando un paio di esempi, ma il take-away importante è usare il separatore di percorso (di solito / in questo contesto) per posizionare gli indirizzi di risorse diverse in modo univoco.

Separa gli indirizzi degli elenchi e il filtraggio degli elenchi dai singoli oggetti indirizzabili. Per esempio.

 POST /users  // Create a user
 GET /users  // Get all users
 GET /users/availability  // Get all users' availability
 GET /user/{id}   // Get user data
 PUT /user/{id}   // Update user data

Qualifica tutti i sottoindirizzi di un elenco, incluso il recupero per ID. Per es.

 POST /users  // Create a user
 GET /users  // Get all users
 GET /users/availability  // Get all users' availability
 GET /users/id/{id}   // Get user data
 GET /users/id/{id}/availability   // Get individual user availability
 PUT /users/id/{id}   // Update user data

Entrambi gli schemi di cui sopra, o variazioni di essi, ti permettono di evitare di sovraccaricare una parte dell'URI con due possibili interpretazioni, quindi non dovrai cercare di analizzare l'URI per determinare il tipo di dati come parte del routing. In genere si desidera evitare questo tipo di analisi, in quanto aggiunge complessità e potrebbe causare errori sul server e / o confusione da parte di persone che scrivono i client sulla propria API.

risposta data 12.07.2017 - 14:57

fonte

Leggi altre domande sui tag php rest

L'inserimento di AddCustomerData, GetAllCustomers e GetCustomerByID in una classe viola l'SRP? Memorizza riferimento a oggetto o funzioni specifiche [chiuso]

score 5 · Accepted Answer

Are REST Resource IDs integers or strings?

Tecnicamente, l'URI è una sequenza di caratteri. Questo non proviene da REST, ma da RFC 3986 "URI (Uniform Resource Identifier): sintassi generica"

Dall'astratto:

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.

Per quanto riguarda REST, l'URI sono chiavi opache; REST non si cura affatto di quale ortografia usi (questo è il motivo per cui gli accorciatori di URL funzionano).

Un componente generico che ha insistito solo sugli interi avrebbe giustamente perso quote di mercato per essere troppo restrittivo.

Nel 1998, Tim Berners-Lee ha scritto

In theory, the domain name space owner owns the domain name space and therefore all URIs in it. Except insolvency, nothing prevents the domain name owner from keeping the name. And in theory the URI space under your domain name is totally under your control, so you can make it as stable as you like.

Ciò significa che, per il tuo dominio, puoi scegliere qualsiasi convenzione di ortografia che ti piace (fatte salve le restrizioni imposte da RFC 3986). Quindi, se vuoi imporre una disciplina a te stesso che dice che le risorse subordinate a questa parte della gerarchia devono essere numeri interi, o devono essere cammelli, o devono essere incantesimi codificati ROT-13 dei nomi dei politici di sinistra del XVIII secolo, Puoi. Sono, dopo tutto, le tue risorse. Puoi identificarli come preferisci.

Quello che probabilmente vuoi nel tuo router è un elenco di regole di corrispondenza con priorità; quindi avresti una corrispondenza esatta per /users/availability e una corrispondenza modello per /users/{id} , e via.