è restful pensato solo per i servizi web OPPURE sia per i servizi web che per le pagine web?

Question

Ho letto molti tutorial Restful per PHP.

(Non voglio approfondire il motivo per cui non sto utilizzando RoR.È dovuto al fatto che il team ha più familiarità con PHP)

Poiché stiamo pianificando una futura espansione verso le API, ho letto che è importante implementare i servizi web Restful.

Ho guardato tutorial come

http://www.gen-x-design.com/archives/create-a-rest-api-with-php/

Apparentemente restful è pensato per i servizi web.

E per le pagine web?possono essere anche RESTFUL?

se la risposta è NO, per favore non andare oltre questa riga E dimmelo e basta.Grazie.

So che per far sembrare gli URL come URL RESTFUL è sufficiente utilizzare mod_rewrite.Tuttavia, ne sono abbastanza sicuro, l'architettura riposante va oltre il semplice rendere gli URL belli.

Ad esempio, ho un elenco di elementi su una pagina Web chiamata list.php.Accanto a ciascun elemento è presente un collegamento di eliminazione.Ad esempio, list.php?id=1&deleteitem

Quello che succede è che quando qualcuno fa clic sul collegamento list.php?id=1&deleteitem, ovviamente torno allo stesso file list.php e controllo il param deleteitem in $_GET.

Se rilevato, lo eliminerò dal database in base all'ID param in $_GET.

Dopodiché reindirizzerò a list.php SENZA alcun parametro.

Mi chiedo, come posso rendere RESTFUL l'intero flusso?

Lo chiedo perché in REST, per eliminare qualcosa è necessario utilizzare il metodo di richiesta HTTP (DELETE).

Chiaramente nei miei link sono tutti semplicemente semplicemente <a href="list.php?id=1&deleteitem">Delete</a>

Per favore illuminami.

La mia programmazione non è così forte e sarebbe bello se i consigli dati fossero il più laici possibile.

Grazie.

MODIFICARE

Ho 2 domande di follow-up.

domanda 1) Poiché questo è un elenco di elementi con paginazione, come apparirebbe l'URL se volessi renderlo RESTful?

domanda 2) Dato che sto inserendo i collegamenti DELETE accanto a ciascuno degli elementi nell'elenco, ora capisco, dovrei usare

<form method="POST">
<input type=hidden name="_method" value="delete">
<input type="submit" >
</form>

Invece.

tuttavia il modulo dovrebbe essere inviato dove?l'URL dell'articolo?/articoli/{id-articolo}

Ma voglio tornare a questa pagina di elenco visualizzando un messaggio di successo DOPO aver eliminato con successo la riga nel database.

Voglio anche evitare un messaggio popup quando aggiorno questa pagina di elenco con un messaggio di successo.

Se pubblico di nuovo a questo URL list.php, non è RESTful, sì?perché le risposte seguenti mi dicono che ogni elemento è una risorsa che necessita del proprio URL.

Per favore illuminami.Grazie.

Answer 1

RESTful è comunemente usato quando ci si riferisce ai servizi web, ma può benissimo applicarsi a pagine web. In poche parole, essendo RESTful è sulla gestione di risorse. Una risorsa può essere una persona, un libro, un film, un teatro, un biglietto, o qualunque cosa tu voglia.

Ci sono quattro operazioni di base è possibile eseguire su una risorsa.

• creare (POST)
• lettura (GET)
• update (PUT)
• Elimina (DELETE)

La maggior parte dei browser web non supportano le azioni PUT e DELETE, in modo da poter utilizzare solo azioni POST per inviare i dati. Rotaie falsi PUT e DELETE passando un parametro nascosta denominata _method che il quadro raccoglie e l'instrada a seconda che il valore.

Inoltre, non si dovrebbe mai usare GET per qualsiasi azione distruttiva. Qualsiasi azione che cambia lo stato della risorsa (s), dovrebbe essere chiamato sia con POST, PUT o DELETE a seconda del cambiamento (finto PUT / DELETE con POST se necessario).

Vorrei suggerire che si verifica il modo di routing RESTful è gestita in Rails solo per avere un'idea, se non altro. Althought le quattro azioni di cui sopra sono sufficienti per modificare una risorsa in ogni modo possibile, Rails introduce anche altri tre tipi di azioni che sembrano utili.

• index (vista della messa in vendita di tutti gli elementi)
• nuovo (di solito una vista modulo per aggiungere un nuovo risorse)
• modifica (di solito un modulo per view aggiornare una risorsa esistente)

Piuttosto URL è sicuramente sul tavolo quando progettazione di siti RESTful, ma probabilmente la vittoria più grande è che la qualità del codice migliora automaticamente. Quando sei solo a che fare con le risorse, e ci sono solo quattro le azioni potenziali che possono essere applicate a una risorsa, poi le cose iniziano a pulire da soli.

Modifica 1 : Auto-descrittivo di URL sono preferiti e renderà la vita più facile, ma non c'è niente impedisce di creare URL criptici che identificano in modo univoco una risorsa e lo gestiscono tramite il protocollo HTTP verbi. URL come quelli sottostanti (utilizzando MD5) per identificare in modo univoco le risorse sono perfettamente RESTful.

// represents a person "John Doe"
http://example.com/4c2a904bafba06591225113ad17b5cec

// represents the movie "Lord of the Rings: The Two Towers"
http://example.com/1d9198260dec7bda3fb21e232d60fec3

// represents the "Formula One" sport
http://example.com/fs340as?id=23xa12&type=SP012Ts

Questo è Representational State Transfer proprio lì. L'hash MD5 è come l'indirizzo postale della risorsa che rimane costante. La rappresentazione potrebbe essere i dettagli del film (in HTML / XML / JSON / etc.), O forse il video del film stesso a seconda delle capacità del cliente).

Modifica 2 : Diciamo che si dispone di una risorsa che è una raccolta - countries del mondo. Potrebbe essere rappresentata da un URI e HTTP verbo come:

GET /countries

Dal momento che il paging è una proprietà della domanda piuttosto che la risorsa stessa, si potrebbe fornire querystring parametri di controllarlo.

GET /countries?page=1

Un paese è anche una risorsa che è una parte della risorsa paesi. Si potrebbe identificare un paese con un URL, ad esempio:

/countries/<id>

e operazioni su questo paese potrebbero essere eseguite con questi verbi:

GET    /countries/<id>
POST   /countries  -- the new country has no existing representation
PUT    /countries/<id>
DELETE /countries/<id>

Answer 2

Risposta lunga breve:SÌ.IL RIPOSO è per entrambi.Questo perché anche se hai il più semplice di tutti i siti web dovresti comunque OTTENERE la tua pagina e magari PUBBLICARE i tuoi dati personali per aggiungere una voce al libro degli ospiti.In questo tutti noi aderiamo in qualche modo al REST.

Nel tuo caso la scarsa implementazione del browser rende difficile implementare un modo PURO RESTful.DELETE non è supportato senza Javascript e quindi dovresti comunque utilizzare GET o POST (che hanno entrambi un significato totalmente diverso da DELETE in REST).

Answer 3

approccio ristoratore può sicuramente essere utilizzato in pagine web pure. Mettere i comandi in un URL non è una buona idea, a causa degli effetti collaterali che si sta menzionare. Quando si modifica il database (o fare quello che cambia il modello), i comandi uso post.

Naturalmente, non avete PUT e delte nei principali browser web, ma si può sempre inviare un semplice post con qualche parametro specifico come method = "PUT", method = "DELETE", ecc.

Answer 4

ho scritto un quadro molto piccolo in cima Zend Framework per rendere l'implementazione di interfacce RESTful facile:

http://github.com/mikekelly/Resauce

È possibile utilizzare che per i servizi web e siti web. In sostanza, un sito web è solo un servizio web guidato da HTML.

Answer 5

RESTful significa non "belli URI".Nonostante il fatto che gli URI identifichino una risorsa, l'unica cosa che REST dice sugli URI è che non dovrebbero contenere un parametro di azione come "elimina".

Nel tuo caso chiameresti

DELETE /items/6793

La risposta sarebbe in genere il codice di stato 200 OK con l'elenco modificato come corpo del messaggio.Vedere: http://restpatterns.org/HTTP_Methods/DELETE

Poiché HTML 4 non supporta altre azioni del modulo oltre a GET e POST, è necessario aggirare il problema con un parametro nascosto e sovrascrivere il metodo HTTP sul lato server.