Estoy buscando una manera de envolver las API en torno a las funciones predeterminadas en mis aplicaciones web, bases de datos y CMS basados ​​en PHP.

He mirado a mi alrededor y he encontrado varios marcos "esqueleto". Además de las respuestas en mi pregunta, hayTónico, un framework REST que me gusta porque es muy ligero.

Me gusta REST por su simplicidad, y me gustaría crear una arquitectura de API basada en ella. Estoy tratando de entender los principios básicos y aún no lo he entendido completamente. Por lo tanto, una serie de preguntas.

1. ¿Lo estoy entendiendo bien?

Digamos que tengo un recurso "usuarios". Podría configurar una serie de URI como así:

/api/users     when called with GET, lists users
/api/users     when called with POST, creates user record
/api/users/1   when called with GET, shows user record
               when called with PUT, updates user record
               when called with DELETE, deletes user record

¿Es esta una representación correcta de una arquitectura RESTful hasta ahora?

2. necesito mas verbos

Crear, actualizar y eliminar puede ser suficiente en teoría, pero en la práctica necesitaré muchos más verbos. Me doy cuenta de que estas son cosas quepodría estar incrustado en una solicitud de actualización, pero son acciones específicas que pueden tener códigos de retorno específicos y no me gustaría incluirlos en una sola acción.

Algunos de los que vienen a la mente en el ejemplo del usuario son:

activate_login
deactivate_login
change_password
add_credit

¿Cómo expresaría acciones como las de una arquitectura de URL RESTful?

Mi instinto sería hacer una llamada GET a una URL como

/api/users/1/activate_login 

y esperar un código de estado de nuevo.

Sin embargo, eso se desvía de la idea de usar verbos HTTP. ¿Qué piensas?

3. Cómo devolver mensajes de error y códigos

Una gran parte de la belleza de REST se debe a su uso de métodos HTTP estándar. En un error, emito un encabezado con un código de estado de error 3xx, 4xx o 5xx. Para una descripción detallada del error, puedo usar el cuerpo (¿verdad?). Hasta ahora tan bueno. Pero ¿cuál sería la forma de transmitir uncódigo de error propietario eso es más detallado al describir lo que salió mal (por ejemplo, "no se pudo conectar a la base de datos" o "inicio de sesión incorrecto en la base de datos") Si lo pongo en el cuerpo junto con el mensaje, tengo que analizarlo después. ¿Hay un encabezado estándar para este tipo de cosas?

4. ¿Cómo hacer la autenticación?

¿Cómo sería una autenticación basada en clave API siguiendo los principios REST?¿Hay puntos fuertes en contra del uso de sesiones al autenticar un cliente REST, aparte de que es una violación flagrante del principio REST? :) (sólo la mitad bromeo aquí, la autenticación basada en sesión funcionaría bien con mi infraestructura existente.)