Introduction
CP has a 3-layer API that targets different audiences:
- People who don't want to worry about HTTP; they just want to start writing "web-enabled" apps.
- People who want to manipulate the HTTP message contents directly.
- People who want to write tools, etc. to manipulate the request process.
Though there can be overlap between those three areas, care has been taken to see that the API adheres to a "need to know" philosophy. That is why, for example, a cherrypy.NotFound exception is raised upon the event of an HTTP 404 status from a server. Someone who fits in category 1 above doesn't care about an HTTP 404 status, and including such information (by raising a HTTPError(404) exception or something) could possibly confuse them.
Sections
- ApplicationObject
- PageHandlers: where most of your application code goes
- RequestObject: cherrypy.request contains request-related data. Pretty lame description, but that's all it does; it's a big data dump. At the beginning of each HTTP request, the existing request object is destroyed, and a new one is created, (one request object for each thread). Therefore, CherryPy (and you yourself) can stick data into cherrypy.request and not worry about it conflicting with other requests.
- ResponseObject: cherrypy.response contains response-related objects. Pretty lame description, but that's all it does; it's a big data dump. At the beginning of each HTTP request, the existing response object is destroyed, and a new one is created, (one response object for each thread). Therefore, CherryPy (and you yourself) can stick data into cherrypy.response and not worry about it conflicting with other requests.
- ConfigAPI
- BuiltinTools and CustomTools: cherrypy.tools is a container for the built-in tools. You can add your own tools and even your own toolboxes.
- ErrorsAndExceptions (including redirects)
- Logging
- EngineObject (see also WebSiteProcessBus)
- ServerObject
Other top-level objects
- cherrypy.thread_data: Holds attributes that map to the "current" thread only. Each request is handled by a single thread, but each thread may handle multiple (sequential) requests. This attribute is a good place to put database connections and other objects that are thread-specific (as opposed to request-specific).
