Come si progetta la mia applicazione per utilizzare REST per se stessa?

0

Non sono sicuro di come chiedere questo. So che questo è semplicistico, ma capisco (credo):

  • REST è un'architettura, non richiesta, semplicemente un modo per creare
  • REST è uno stile e uno standard di comunità per il trasferimento dei dati
  • REST usa verbi e sostantivi, in particolare il secondo, GET, POST, PUT, DELETE ...

Mentre leggo vedo solo l'architettura dal punto di vista dei consumatori e il creatore dell'API per il consumatore.

Quello che non riesco a trovare è come farlo solo per la mia applicazione. Cosa succede se non sto condividendo nulla con nessuno al momento. Voglio costruire la mia applicazione per seguire questa architettura per il futuro.

Che cosa faccio adesso? Se voglio usare questo tipo di costrutto:

Esempi :

  • PUT http://www.example.com/customers/12345
  • PUT http://www.example.com/customers/12345/orders/98765
  • PUT http://www.example.com/buckets/secret_stuff

La mia applicazione, quando creo una nuova persona, uso un% di HTML% co_de Ora come faccio a fare questo con PUT? Dove va questo?

Se utilizzo http://www.example.com/customers/12345 come faccio a sapere in la mia applicazione che voglio PUT o GET o qualsiasi altra cosa?

Sto usando MVC, dov'è la mia azione? Mi rendo conto che il consumatore potrebbe usare la mia architettura / servizio con nomi, ma questo è solo per me. Come faccio a sapere cosa fare, se non riesco a utilizzare PUT in un tag form?

In questo momento utilizzo la mia pagina PHP per afferrare la stringa di query basata su una RewriteRule:

require_once("database\adapters\PDO\Database.bootstrap.php");
class App {
    protected $_controller = 'Welcome';
    protected $_method = 'index';
    protected $_params = [];
    protected $_model = 'Welcome';

    public function __construct(){
    $url = $this->parseURL();
    //This works because I put the rewrite rules in IIS; 
    //Our RewriteRule in IIS (or Apache) is ^(.+)$  This is any character saved to a variable.
    //The new location is index.php?url=$1 [QSA, L].  This will look a little different after you import it into IIS.

    if (file_exists('app\controllers\' . $url[0] . '.controller.php')){
        $this->_controller = $url[0];
        $this->_model = $url[0];
        unset($url[0]);  //Unset removes that element from the array; 
        //var_dump($url);
    }

    //Get the controller and model.  All done by convention over configuration;
    require_once 'app\controllers\' . $this->_controller . '.controller.php';
    require_once 'app\models\Parent.model.php';

    //get a new Database object from the bootstrap;
    $_DB = new DatabaseBootstrap();

    $this->_controller = $this->_controller . "Controller"; 

    $this->_model = new ParentModel($_DB->getAdapter());
    $this->_controller = new $this->_controller($this->_model);

    //This checks to see if our method from the url exists;
    //Your querystring will look like this - http://server/virtualdirectory/controller/action/variables1/variable2.....

    if(isset($url[1])){
        if(method_exists($this->_controller,$url[1])){
            $this->_method = $url[1];
            unset($url[1]);
        }
    }

    $this->_params = $url ? array_values($url) : [];

    //This calls your controller and your method and sends over your array of parameters
    call_user_func_array([$this->_controller, $this->_method],$this->_params)
}

public function parseURL(){
    if(isset($_GET['url'])){
        return $url = explode('/',filter_var(rtrim($_GET['url'],'/'),FILTER_SANITIZE_URL));
        }
    }

EDIT: in base alla mia lettura delle risposte, sembra che non sia possibile utilizzare REST in modo nativo come quando si utilizzano i verbi HTTP. O devo usare il nome dei tipi in AJAX o devo avere un campo nascosto che contiene il mio metodo REST in questo modo (esempio da cakePHP ):

<form id="RecipeEditForm" method="post" action="/recipes/edit/5">
<input type="hidden" name="_method" value="PUT" />

E sembra che ciò sia fatto per il "bene superiore". Cioè, in modo che altri possano consumare i miei servizi API utilizzando librerie come curl o usando AJAX dove è possibile creare qualsiasi metodo di richiesta che desiderano (?). Dal momento che stiamo usando un'architettura REST, il consumatore che utilizza l'API potrebbe semplicemente mettere PUT, DELETE, ecc. Alcune architetture future potrebbero non utilizzare quei verbi, quindi creiamo nuove parole chiave. È solo che PUT, ecc. Sono nelle specifiche w3 per HTTP, che non sono molto ben supportate.?

    
posta johnny 02.10.2014 - 16:27
fonte

4 risposte

1

Un popolare framework php consente di simulare le richieste PUT / DELETE aggiungendo un argomento _method = PUT all'azione del modulo:

<form method="POST" action="/customers/12345?_method=PUT">

Internamente, il framework converte la richiesta POST in una richiesta PUT.

link

Abbastanza facile da implementare. Ma seguirò il consiglio di @ vrostu e cercherò un framework REST javascript invece di provare a usare i moduli.

    
risposta data 02.10.2014 - 18:48
fonte
2

I moduli HTML possono essere inviati solo da GET e POST. Molte applicazioni che utilizzano i servizi REST non si basano su moduli HTML a causa di queste limitazioni e inviano invece dati da AJAX in cui non ci si limita a due soli verbi. Esistono infinite librerie esistenti per fare ciò in Javascript (jQuery, Angular $ http, ecc.). Inoltre, non si è limitati a dati codificati in moduli su AJAX: ad esempio, è possibile inviare JSON o XML dalla pagina, se è più comodo.

    
risposta data 02.10.2014 - 17:36
fonte
1

How do I know what to do, if I can't use PUT in a form tag?

Sembra che ci sia una certa confusione tra l'applicazione (il server) e un possibile client dell'applicazione (il browser Web che comunica con il server). Sicuramente puoi usare PUT sul server.

Come dice vrostu, i browser Web usano HTML e HTML non ha funzionato bene con HTTP. HTTP ha avuto questi verbi dalla fine degli anni '90, ma l'HTML non è stato aggiornato per consentire una facile costruzione di moduli di siti web che utilizzano questi verbi. Penso che HTML 5 stia cambiando questo, lentamente.

Quando si progetta il server, è meglio ignorare ciò che il client utilizzerà per comunicare e progettarlo correttamente nel modo in cui si desidera progettarlo, utilizzando tutti i verbi HTTP. È possibile utilizzare altri strumenti per comunicare con esso anziché i moduli Web HTML.

Quando sei felice che il server funzioni bene, cerca di utilizzare una libreria javascript per hackerare la pagina web per inviare la richiesta HTTP corretta.

    
risposta data 02.10.2014 - 18:31
fonte
1

I my application, when I create a new person, I use an HTML Now how do I do this with PUT? Where does this go?

Non lo fai. Se si utilizza HTML come rappresentazione dello stato dell'applicazione, i collegamenti forniti nell'ipertesto utilizzano GET o POST. Sì, puoi provare a falsificare PUT / DELETE tramite post, ma il client non riconoscerà tali azioni come identi- ficenti, né le varie cache, i proxy inversi, ecc. Tra il tuo server e l'applicazione. Non combattere le maree; avrai molte meno sorprese lungo la strada.

Se togli l'HTML dall'immagine, la storia cambia. Ad esempio, se vuoi usare JSON come rappresentazione di stato, le tue risorse possono supportare direttamente i metodi PUT e DELETE.

Non c'è ragione per cui il tuo server non possa fare entrambe le cose. Fornire rappresentazioni html dello stato dell'applicazione con collegamenti GET / POST e fornire rappresentazioni json con stato dell'applicazione che include anche collegamenti PUT / DELETE. La trama di base è che quando un cliente arriva al tuo servizio, tu dai loro la rappresentazione che corrisponde al tipo di contenuto supportato dal client, e da quel punto, il client segue semplicemente i collegamenti forniti dal server.

Le risorse non sono necessariamente 1-1. Ad esempio, se vuoi creare una "creazione" idempotente, usare PUT è perfetto ... ma non in HTML, dove put non è supportato. Probabilmente finirai per fare un POST e per una risorsa diversa. Quindi, a livello di rappresentazione, hai più lavoro da fare che trasformare semplicemente json in html.

If I use http://www.example.com/customers/12345 how do I know within my application that I want to PUT or GET or whatever?

Relazioni di link e tipi di media. Cioè, il link nello stato della tua applicazione include metadati che descrivono il tipo di collegamento, e la documentazione della tua API dice al programmatore dell'applicazione quali significati sono associati a quel link.

Ad esempio, rivedi la specifica Paging Feed . Lo stato dell'applicazione fornisce l'url e la relazione di collegamento. La tua specifica API spiega la semantica della relazione.

<link 
    rel="http://www.example.com/docs/links/relations/create"
    href="http://www.example.com/customers/12345"
    ...
/>

L'uso dell'identificatore della documentazione come l'ortografia della relazione di collegamento rende davvero facile per gli sviluppatori trovare i documenti, ma non è necessario farlo; avrai notato che le specifiche dei feed di paging utilizzano le ortografie "next", "previous" e così via.

    
risposta data 23.01.2016 - 01:26
fonte

Leggi altre domande sui tag