REST APIs are a very common topic nowadays; they are part of almost every web application. A simple, consistent and pragmatic interface is mandatory and it will be much easier for others to use your API. Even if these practices may look common to you, I often see projects that don't really respect them. That's why I compiled this list. Here are some best practices to keep in mind while designing a RESTful API.
API versions are mandatory. This way, you will be futureproof as the API changes
through time. One way to do this is to pass the API version in the URL (e.g.
/api/v1/...
). Another neat trick is to use the Accept
HTTP header to pass
the verison
desired. Github does that.
Using versions will allow you to change the API structure without breaking
compatibility with older clients.
I see a lot of projects using verbs instead of nouns in their resource names. Here are some bad examples:
/getProducts
/listOrders
/retreiveClientByOrder?orderId=1
For a clean and conscice structure you should always use nouns. Moreover, a good use of HTTP methods will allow you to remove actions from your resources names. Here is a much cleaner example :
GET /products
: will return the list of all productsPOST /products
: will add a product to the collectionGET /products/4
: will retreive product #4PATCH/PUT /products/4
: will update product #4It isn't a really good idea to mix singular and plural forms in a single
resource naming; it can quickly become confusing and non-consistent. Use
/artists
instead of /artist
, even for the show/delete/update actions
RFC2616 cleary states that HEAD and GET methods should always be safe to call (in other words, the state should not be altered). Here is a bad example:
1 | GET /deleteProduct?id=1
|
Imagine a search engine indexing that page?!?
If you want to get a sub collection (collection of another one), use nested routing for a cleaner design. For instance, if you want to get a list of all albums of a particular artist, you would want to use :
1 | GET /artists/8/albums
|
Returning a very large resultset over HTTP is not a very good idea either. You will eventually run into performance issues as serializing a large JSON may quickly become expensive. An option to get around that would be to paginate your results. Facebook, Twitter, Github, etc. do that. It's much more efficient to make more calls that takes little time to complete, than a big one that is very slow to execute.
Also, if you are using pagination, one good way to indicate the next and previous pages links is through the Link HTTP header. Github does that too.
Always use proper HTTP status codes when returning content (for both successful and error requests). Here a quick list of non common codes that you may want to use in your application.
201 Created
should be used when creating content (INSERT),202 Accepted
should be used when a request is queued for background
processing (async tasks),204 No Content
should be used when the request was properly executed but no
content was returned (a good example would be when you delete something).400 Bad Request
should be used when there was an error while processing the
request payload (malformed JSON, for instance).401 Unauthorized
should be used when a request is not authenticiated (wrong
access token, or username or password).403 Forbidden
should be used when the request is successfully authenticiated
(see 401), but the action was forbidden.406 Not Acceptable
should be used when the requested format is not available
(for instance, when requesting an XML resource from a JSON only server).410 Gone
Should be returned when the requested resource is permenantely
deleted and will never be available again.422 Unprocesable entity
Could be used when there was a validation error
while creating an object.A more complete list of status codes can be found in RFC2616.
When an exception is raised, you should always return a consistent payload describing the error. This way it will be easier for others to parse the error message (the structure will always be the same, whatever the error is).
Here's one I often use in my web applications. It is clear, simple and self-descriptive.
1 2 3 4 5 6 | HTTP/1.1 401 Unauthorized { "status": "Unauthorized", "message": "No access token provided.", "request_id": "594600f4-7eec-47ca-8012-02e7b89859ce" } |
Running Flask's Hello World. Create a new Python file called app.py
and
copy/paste the Hello world code from
Flask’s homepage:
1 2 3 4 5 6 7 8 9 | from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!" if __name__ == "__main__": app.run() |
Connect to your database. Use SQLAlchemy to create and connect to our SQLite database. Replace the previous route code with a few lines of configuration for your database code to make your Python script look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | from flask import Flask from flask.ext.sqlalchemy import SQLAlchemy app = Flask(__name__) app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///people.db' db = SQLAlchemy(app) class Person(db.Model): id = db.Column(db.Integer, primary_key=True) first_name = db.Column(db.Text) last_name = db.Column(db.Text) db.create_all() if __name__ == "__main__": app.run() |
Creating the RESTful API. We'll use Flask-Restless to build the RESTful API. You only need to add three lines of code. Import the APIManager, then create the API using the APIManager as shown in the code below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | from flask import Flask from flask.ext.restless import APIManager from flask.ext.sqlalchemy import SQLAlchemy app = Flask(__name__) app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///people.db' db = SQLAlchemy(app) class Person(db.Model): id = db.Column(db.Integer, primary_key=True) first_name = db.Column(db.Text) last_name = db.Column(db.Text) db.create_all() api_manager = APIManager(app, flask_sqlalchemy_db=db) api_manager.create_api(Person, methods=['GET', 'POST', 'DELETE', 'PUT']) if __name__ == "__main__": app.run() |
Open the browser to execute a GET request and see the results. You can also select a specific Person by id by appending the id to the url. Using these APIs, you can now GET, POST, DELETE, and PUT data and you’ve laid the groundwork for your application.