2012-08-08 33 views
5

Tengo una aplicación CakePHP simple que permite a un usuario crear y editar publicaciones. Y estoy buscando la aplicación en PhoneGap en algún momento en el futuro.Crear API usando CakePHP

Por lo tanto, he creado una API que escupe JSON para usar en solicitudes AJAX, pero tengo la sensación de que lo estoy haciendo mal ya que no estoy usando REST o haciendo algo diferente que lo diferencie de otro código en el controlador.

p. Ej. (NOTA: Me falta la parte sobre convirtiéndolo en JSON para este ejemplo)

class ApiController extends AppController { 

    function index() { 
     $posts= $this->Post->find('all'); 
     $this->set(compact('posts')); 
    } 
} 

para crear una URL como: domain.com/api/posts/all (crearía ruta personalizada para lograr esto) que luego puede llamar usando AJAX para usar en mi aplicación móvil.

Ahora mi pregunta es ¿qué otra cosa sería hacerlo usando REST? Soy muy novato en la creación de aplicaciones y mis fortalezas están en el desarrollo de aplicaciones de usuario y no en aplicaciones de back-end, así que cualquier sugerencia, ayuda con esto sería muy apreciada.

+0

Si usa Sencha Touch dentro de su aplicación PhoneGab, también puede usar una [Implementación Ext.Direct] (http://banchaproject.org) en lugar de RESTful. –

Respuesta

3

Activando REST en CakePHP básicamente enruta los métodos HTTP adecuados a las acciones. Por lo tanto, una solicitud GET se enrutaría a una acción de índice o vista, una solicitud DELETE enviada a la acción de eliminación, y así sucesivamente.

Esto crea un punto final muy fácil para las personas que usan su API. A continuación, cuando se llama a este punto final, dependiendo del método HTTP se endurece en ruta a la acción adecuada (valga cualquier error de sintaxis petición HTTP):

// single endpoint 
http://example.com/api/posts 

una petición GET que las rutas a /posts/index.json

GET /api/posts.json HTTP/1.1 
Host: example.com 
solicitud

un puesto que las rutas a /posts/edit/1.json

POST /api/posts/1.json HTTP/1.1 
Host: example.com 
Content-Type: application/x-www-form-urlencoded; charset=utf-8 
Content-Length: 24 

data[Post][name]=updated 

la lectura de este responderá a la mayor parte de sus preguntas: http://book.cakephp.org/2.0/en/development/rest.html

+0

Bien dicho eso ... ¿Cómo difiere de la creación de métodos estándar en el controlador sin usar REST? También esto podría parecer una pregunta diferente, pero ¿qué ofrece el método DELETE sobre los métodos POST o GET para formularios? – Cameron

+0

Por un lado, es más fácil para los desarrolladores y para usted (crear documentos). Menos puntos finales En segundo lugar, * requeriría * el método HTTP adecuado. Por ejemplo, los usuarios ya no pueden visitar '/ api/posts/delete/1' en su navegador y eliminar una publicación, en realidad tendrían que solicitar un DELETE utilizando el método apropiado. Además, el sistema REST de Cake te permitirá aceptar diferentes tipos de contenido y decodificarlo automáticamente en '$ this-> request-> data' para ti.Si no funciona para usted, entonces no es necesario hacerlo, pero es la forma correcta de crear una API RESTful. – jeremyharris

3

Si su preocupación es ser fiel a los principios de Rest.

Entonces, generalmente existen 4 puntos a tener en cuenta:

  • URI base para el servicio web
  • El tipo de medios de Internet de los datos soportados por el servicio web.
    Esto a menudo es JSON, XML o YAML, pero puede ser cualquier otro tipo de medio válido de Internet .
  • El conjunto de operaciones admitidas por el servicio web utilizando los métodos HTTP (por ejemplo, GET, PUT, POST o DELETE).
  • La API debe ser impulsado hipertexto

Sede, http://en.wikipedia.org/wiki/Representational_state_transfer para más detalles.

Ahora, dicho esto, sugeriría cambiar el código anterior para que sea similar a los pseudocódigos siguientes.

1) La existencia de recursos es clave, piense en sus publicaciones como una colección de recursos a los que se puede acceder mediante un URI.(Autenticación & autorización son otros problemas que también puede ser que desee para manejar):

api.domain.com/resources/posts => este URI apunta a una colección de Mensajes

2) El conjunto de operaciones que tendrá que soportar el uso de métodos HTTP/verbos necesitan definido, como ejemplo lo que se quiere recuperar un solo miembro de la colección al hacer esto:

api.domain.com/resources/posts/12

A continuación se muestra el encabezado de solicitud & cuerpo que se puede encontrar en un entrante solicitud de este URI:

Accept: application/json
Content-Type: application/json
solicitud de URL: http://api.domain.com/resources/posts/12
Solicitud Método: GET

Su aplicación debe ser capaz de manejar ese tipo de solicitud, sin la necesidad de estipular la operación en el URI, lo que nos devuelve al punto (1),

en lugar de tener un URI escrito de esta manera:

domain.com/api/posts/ todo

Su URI debe ser modelo de esta manera:

recursos/mensajes/12 como recursos/tipo/artículo para recuperar uno de los miembros de la colección,
recursos/publicaciones como recursos/tipo para trabajar con toda la colección.

He aquí un ejemplo de códigos:

clase abstracta Común Aquí podría implementar algunas tareas comunes. Si está utilizando una implementación basada en el servicio , esto también podría realizarse mediante un servicio.

abstract class ResourcesController extends AppController { 
} 


class PostResourcesController extends ResourcesController { 

    /** 
    * By the time this method is called in your controller/class, you already know 
    * that the HTTP method is GET. 
    * 
    * @param Request\$_GET $request A request instance 
    * @param int   $postId The post ID to retrieve 
    * 
    * @return Response A reponse instance 
    */ 
    function getPost(Request $Request, $postId = null) 
    { 
     /** 
     * Here you can use the request object to get 
     * the response content type  
     * the requesting client accepts. Example JSON or XML. 
     */ 

     /** 
     * using the $postId you can then query your database 
     * to retrieve a post with that ID or use a sort of 
     * service. 
     */ 

     /** 
     * Once you implemented a you logic 
     * you can build a response to return. 
     */ 
    } 
} 

Este código es incompleta, pero espero que da usted una idea de lo que es un verdadero API reparador podría ser similar.

La clave para asegurarse de que
"la aplicación puede interactuar con un recurso conociendo dos cosas: el identificador del recurso y la acción requerida".

Afortunadamente, esto ayudó.