01 October 2014
Retrieving Data with GET
Symfony Web Service Part 2
This article is part of a series about how to build a web wervice for an iOS eLearning iPad app. So far there have been articles on Introduction Symfony Web Service and Creating Data with POST.
NOTE: The project database stores data coming from different iOS apps. That’s why the URIs in this article need to include information about the application we are refering to. If your web service is used just for one application, it won’t be necessary that you specify this field in your URIs.
NOTE: The following recommendations come from the Internet Engineering Task Force (IETF) and the Internet Society, the principal technical development and standards-setting bodies for the Internet.
Every time a user completes a test and submits his results, a log is sent to the web service, including information about the user and the status of the corresponding module coming from the eLearning app.
This article shows how I did it to retrieve the list of an user’s logs for a specific application.
Building up the request
I will start by building-up the request, which is sent from the client to the server. As I am retrieving a resource collection (user’s logs), I will choose GET as the HTTP method. I will also need to specify the address or URI to that collection.
Let’s summarize all the fields to be included in the GET request:
The GET request for this case will end up looking something like this:
Building up the response
Once the request is ready, I will focus on building up the response, which is sent from the server to the client. Generally the correct status code for all GET requests is 200.
Let’s summarize all the fields to be included in the response:
|Status Code||200 OK|
|Response Body||Representation of a user resource including his logs|
The response will end up looking something like this:
Please note that the body content is the same as in the response using POST in the next article. However the status code will be different in each case.
Building up the server endpoint
The last thing I will be doing is to build up the server endpoint. For that, I will be adding first the new route to the routing file and redirect the URL to the listAction located in the controller:
The server endpoint to get the list of the user’s logs will end up looking like this:
If something went wrong in the server side, the response will look a little bit different. It can be that the application, the module or the user sent in the request is not found in our database (404 Not Found). I will still be sending some JSON-formatted data in the response body, but its Content-Type will be partialy different.
By sending back a Content-Type header of application/problem+json we will be telling the client that something went wrong in the server side. This is called the media type of the document and you can find all the official recognized types in the Internet Assigned Numbers Authority (IANA). Actually the application/problem+json isn’t in this list because it’s just a draft at the moment of writing this article.
Let’s summarize all the fields to be included in the response paying attention to the information included in the body:
|Status Code||404 Not Found|
|Response Body||Error information: type, title and error message.|
I built a specific function in the controller to handle errors, which builds up the response with its corresponding headers:
NOTE: At the moment of writing this article, there’s no standard for how error responses should look like. In this case I included these fields: type, title, and errors. This is part of a potential standard called API Problem, or Problem Details. You can check the corresponding RFC document here. It is important to know that this document may change in the future or be discarded entirely for something different.
- API Problem
- RFC 2616 - Status Code Definitions
- RESTful APIs in the Real World Episode 1 - Knp University
If you liked this article, share it with your followers ♥