Entender la Columna Vertebral.llamadas REST de js

Si no te importa, voy a empezar aclarando algunas palabras. REST no es un protocolo en sí mismo, es simplemente una forma de usar el protocolo HTTP. El estilo REST es especialmente útil para las API, como espero que veas. Cuando una API se ajusta a ese estilo, se dice que es "RESTful". Si la API con la que estás trabajando no es RESTful, tendrás que hacer muchos cambios en Backbone.sincronizar con el fin de conseguir que funcione. Así que espero que lo sea! :)

El Protocolo HTTP

Me gusta ejemplos, así que aquí hay una solicitud HTTP para obtener el HTML de esta página:

GET /questions/18504235/understand-backbone-js-rest-calls HTTP/1.1
Host: stackoverflow.com

[Opcional] Si alguna vez ha jugado con la línea de comandos o terminal, intente ejecutar el comando telnet stackoverflow.com 80 y pegar el anterior, seguido de presionar enter un par de veces. ¡Voila! HTML en toda su gloria.

En este ejemplo...

• GETes el método .
• /questions/18504235/understand-backbone-js-rest-callses el camino .
• HTTP/1.1es el protocolo .
• Host: stackoverflow.com es un ejemplo de un encabezado .

Su navegador hace aproximadamente lo mismo, solo que con más encabezados, para obtener el HTML de esta página. Genial, ¿eh?

Desde que trabajas en front end, probablemente hayas visto la etiqueta de formulario muchas veces. He aquí un ejemplo de uno:

<form action="/login" method="post">
    <input type="text" name="username" />
    <input type="password" name="password" />
    <input type="submit" name="submit" value="Log In" />
</form>

Cuando envía este formulario junto con los datos apropiados, su navegador envía una solicitud que se ve algo como esto:

POST /login HTTP/1.1
Host: stackoverflow.com

username=testndtv&password=zachrabbitisawesome123&submit=Log%20In

Hay tres diferencias entre el ejemplo anterior y este.

1. El método es ahora POST.
2. El camino es ahora /login.
3. Hay una línea extra, llamada el cuerpo .

Si bien hay un montón de otros métodos, los que se utilizan en aplicaciones RESTful son POST, GET, PUT, y DELETE. Esto le dice al servidor qué tipo de acción se supone que debe realizar con los datos, sin tener que tener diferentes rutas para todo.

Volver a Backbone

Así que espero que ahora entiendas un poco más sobre cómo funciona HTTP. Pero, ¿cómo se relaciona esto con Backbone? ¡Averigüémoslo!

Aquí hay una pequeña parte de código que puede encontrar en una aplicación troncal.

var BookModel = Backbone.Model.extend({
    urlRoot: '/books'
});
var BookCollection = Backbone.Collection.extend({
    model: BookModel
    , url: '/books'
});

Crear (POST)

Dado que estamos utilizando una API RESTful, ¡esa es toda la información que Backbone necesita para poder crear, leer, actualizar y eliminar toda la información de nuestro libro! Empecemos por hacer un nuevo libro. El siguiente código debe basta:

var brandNewBook = new BookModel({ title: '1984', author: 'George Orwel' });
brandNewBook.save();

Backbone se da cuenta de que está tratando de crear un nuevo libro, y sabe por la información que se le ha dado para hacer la siguiente solicitud:

POST /books HTTP/1.1
Host: example.com

{"title":"1984","author":"George Orwel"}

Read (GET)

¿Ves lo fácil que fue? Pero queremos recuperar esa información en algún momento. Digamos que corrimos new BookCollection().fetch(). Backbone entendería que estás tratando de leer una colección de libros, y haría la siguiente petición:

GET /books HTTP/1.1
Host: example.com

BAM. Así de fácil. Pero digamos que solo queríamos la información para un libro. Digamos el libro # 42. Digamos que corrimos new BookModel({ id: 42 }).fetch(). Backbone ve que estás tratando de leer un único libro:

GET /books/42 HTTP/1.1
Host: example.com

Actualizar (PUT)

brandNewBook.set('author', 'George Orwell');
brandNewBook.save();

Backbone es lo suficientemente inteligente como para saber que a pesar de ser llamado brandNewBook, ya ha sido guardado. Así que actualiza el libro:

PUT /books/84 HTTP/1.1
Host: example.com

{"title":"1984","author":"George Orwell"}

Suprimir (SUPRIMIR)

Finalmente, usted date cuenta de que el gobierno está siguiendo todos tus movimientos, y necesitas enterrar el hecho de que has leído 1984. Probablemente sea demasiado tarde, pero nunca está de más intentarlo. Así que corres brandNewBook.destroy(), y Backbone se vuelve sensible y se da cuenta de tu peligro elimina el libro con la siguiente petición:

DELETE /books/84 HTTP/1.1
Host: example.com

Y se ha ido.

Otras Cositas Útiles

Si bien hemos hablado mucho sobre lo que estamos enviando al servidor, probablemente también deberíamos echar un vistazo a lo que vamos a recuperar. Volvamos a nuestra colección de libros. Si recuerdas, hicimos una GET petición a /books. En teoría, deberíamos recuperar algo como esto:

[
    {"id":42,"author":"Douglas Adams","title":"The Hitchhiker's Guide to the Galaxy"}
    , {"id":3,"author":"J. R. R. Tolkien","title":"The Lord of the Rings: The Fellowship of the Ring"}
]

Nada demasiado aterrador. Y aún mejor, Backbone sabe cómo manejar esto fuera de la caja. ¿Pero y si lo cambiamos un poco? En lugar de id ser el campo de identificación, fue bookId?

[
    {"bookId":42,"author":"Douglas Adams","title":"The Hitchhiker's Guide to the Galaxy"}
    , {"bookId":3,"author":"J. R. R. Tolkien","title":"The Lord of the Rings: The Fellowship of the Ring"}
]

Backbone consigue que cada API sea un poco diferente, y está bien con eso. Todo lo que tienes que hacer es dejarlo conoce el idAttribute, así:

var BookModel = Backbone.Model.extend({
    urlRoot: '/books'
    , idAttribute: 'bookId'
});

Solo tiene que agregar esa información al modelo, ya que la colección comprueba el modelo de todos modos. Así que así como así, Backbone entiende su API! Incluso si no lo hago...

La desventaja de esto es que tienes que recordar usar bookId en ciertos casos. Por ejemplo, donde antes usábamos new BookModel({ id: 42 }).fetch() para cargar los datos de un solo libro, ahora tendríamos que usar new BookModel({ bookId: 42 }).fetch().

Esperamos que haya encontrado esta respuesta informativo, y no demasiado insoportablemente aburrido. Me doy cuenta de que para muchos, el protocolo HTTP y la arquitectura RESTful no son los temas más estimulantes, así que traté de darle un poco de sabor. Puede que me arrepienta cuando lea todo esto en un momento posterior, pero son las 2 AM aquí, así que voy a seguir adelante y presentar esto de todos modos.