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ó.
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. –