Endpoints are the terminal step in process of serving a request. (See the docs on filters to see what the intermediate steps might be.) An endpoint can simply be viewed as the logic that is ultimately responsible for generating a response to a particular request. You create an endpoint by annotating a function like so:
This annotation specifies that this function is responsible for generating the response to any
GET request to
/hello. (If you’re unfamiliar with
POST HTTP requests, you can read up on them here.) Typically, the value returned from the function will be used as the response to the request (after being serialized through a serializer to e.g. convert the response into JSON). In this case, a
GET response to
/hello would return the content
["hello world"] with a JSON content-type, unless you’ve changed the serializer type.
Endpoints can be specified for any of the four major HTTP “verbs”:
DELETE using the annotations
@delete, respectively. As you might expect, a function annotated with
@get will respond only to
GET requests. So if you intend an endpoint to be accessed via multiple HTTP methods, you would need to annotate them with each relevant method as in:
If an endpoint generates an error, the error handler will generate a response on behalf of the endpoint. By default, this involves capturing the error message and returning a serialized response with an HTTP status code of
500 to signify a server error.
Below on the left you’ll find a web application that uses jQuery to send requests to a plumber API which processes those requests. You can edit the slider inputs to preview what the request would look like before submitting it to the API. The code for the plumber API is included on the right so you can see how each endpoint would behave.
The plumber server is hosted at
Click "Post" to see the response.
Click "Get" to see the response.