-
Notifications
You must be signed in to change notification settings - Fork 2
Rest
camposer edited this page Aug 15, 2012
·
10 revisions
I've developed a very simple RESTful app, only considers CRUD operations over an user entity.
I followed some good recommendations mentioned in this article, shared by jjeronimo.
In general, the API is:
- getUsers. Retrieves all users (SELECT * FROM user).
curl -X GET http://localhost:3000/rest/users
- getUsersById. Retrieves an user by its id (SELECT * FROM user WHERE id = ?).
curl -X GET http://localhost:3000/rest/users/1
- addUser. Adds an user (INSERT INTO user(name) VALUES(?)).
curl -X PUT -H "Content-type:application/x-www-form-urlencoded" -d "name=rodolfo" http://localhost:3000/rest/users
- updateUser. Updates an user (UPDATE user SET name = ? WHERE id = ?).
curl -X DELETE -H "Content-type:application/x-www-form-urlencoded" -d "id=1&name=juan" http://localhost:3000/rest/users
- removeUser. Removes an user by its id (DELETE FROM user WHERE id = ?).
curl -X DELETE -H "Content-type:application/x-www-form-urlencoded" -d "id=1" http://localhost:3000/rest/users
As you can see, the URLs follow the pattern: rest/users. Some comments about this:
- URLs start with the word "rest" for easily identifying them as part of the REST API. Another part indicating the API version can be added, like: rest/v1/users (util for backwards compatibility issues).
- A REST API should be easy to discover, just adding and removing parameters. For example: if you want all users can use
/users, but if you want an specific user can use/users/1. Maybe a better option, for more complex cases, could be:/users/id/1, because this way results "evident" something like:/users/name/rodolfo/status/0. However, I prefer to specify getXxxById following the entity name (written in plural) by its id.
- Facade-Service
- Routing
- HTTP Status
- "call" method in common.js
- Some testing using cURL