Rest Api

Updated 25 February 2022

Facebook Linkedin

Rest Api with Symfony

In this article, I will describe our journey with developing Rest API. Our Previous Api development articles are listed below:

  1. Soap vs Rest


Before developing Api, it is wise to outline your requirements for developing Api.

Our Use Case: Develop a secure and robust Rest Api for helpdesk system, which supports at least json format. Api could be used to serve specific purpose data (like tickets, replies) and develop mobile Apps. It should be easily scalable and customizable for future needs.

here, I will be using PHP with Symfony framework and bundles & libraries like FOSRestBundle, FOSOAuthServerBundleNelmioApiDocBundle. Even if you don’t want to use PHP you will get a fair idea about REST Api development.

Basics for REST API:

Restful Api should correlate with following standards,

Rest Api should use corresponding HTTP methods for CRUD like operations.

Action HTTP Method, example route
fetch single resource like ticket with json format: GET /ticket/5.json
fetch collection of resource like ticket with json format: GET /tickets.json
add resource like ticket with json format: POST /tickets.json
edit resource like ticket with json format: PUT /ticket/5.json
delete resource like ticket with json format: DELETE /ticket/5.json

Also, Response should be returned with suitable HTTP Status codes. wiki

Status Code Inference
200 Success: Status OK
201 Success: Resource created
400 Client Error: Bad Request
401 Client Error: Unauthorized
403 Client Error: Forbidden
404 Client Error: Not found
421 Client Error: Too Many Request
5xx Server Error

More advantages of Rest can be found here.

Let’s Dive into Rest Api with Symfony

While developing Api, don’t reinvent the wheel unless you need to. There is a lot of libraries, open-source work which could speed-up your work.

Symfony community has already created a set of tools (libraries, bundles) to ease the development of HTTP/REST APIs. it have a couple of well-known bundles such as the FOSRestBundle and the NelmioApiDocBundle.

We used FOSRest Bundle for setting up Rest Architecture. find instructions here

Problems that we faced along the way
1. fosrest conflict with sensio/framework-extra-bundle: >=3.0.13

Solution: try using sensio/framework-extra-bundle to 3.0.12 with friendsofsymfony/rest-bundle: 1.8

2. using fosrest without jmsserializer

solution: enable default symfony serializer service

or use custom fos_rest.service.serializer service

3. conflict with non-api routes, like form can only be submitted once error.

solution 1:

disable body listener

solution 2:

or enable zone listener


Now, configured routes (like given below) can be used like restful URI corresponding to resources.


After Successfully configuring fosrest, API

1.  provides a suitable response based on the format in a request like resource.json, resource.xml

2. accepts request data-based Content-Type header.

How to Secure your API?

fosrest bundle does provide rest architecture for your API. but you still need to secure your API.

how the API Security layer differs from the conventional web security layer?

Conventional web resources like web pages can be protected by Username & Password combination.

Moreover, web resources often follow the stateful strategy in which credentials are stored in the HttpSession object, in a database session, cookie, or otherwise.

But, API Requests to Server are Stateless. so, API uses different Authentication and Authorization Schemes. Since API Resources can be shared publically. API would need a secure way to Authenticate and Authorize all Requests. We came across some prevailing standards and analyzed them for our use case.

Basic Authentication:

In basic authentication, Username/Password are base64 encoded and sent as Authorization header. Read more

Example Request:

what’s we found out:
Compromise of Secret Token can compromise Username and password.
There is no expiration time for Secret Token.

API Key:

API Key is a unique long string (128-bit) assigned to the user. It is used for quite similar functions as username/password, allowing access to specific resources. Many API providers have opted to use API Key in the Security layer like early Google API.

Example Request:

What are we found out:
API key is a good way to secure API for specific use. however, the API key becomes troublesome when scaling API to encompass third-party apps and extending use beyond what they were originally intended for. so, API Keys Are Not a Complete Solution.


Furthermore, After going through other standards like HMAC which involves signing the message by access key and OAuth i.e. open standard for authorization. We decided to use Oauth2.0 for securing our API.

Why did we choose OAuth2?

Apart from the fact that Google, Facebook, Twitter, Microsoft, and others are shifting to OAuth2 from other standards. I would list some facts why OAuth2 is a correct choice:

  • OAuth2 is the newer version of OAuth Protocol. it’s simpler than OAuth1.
  • It uses an Access token with a limited lifetime to authorize the request. So, the exploit window is quite small and more secure in Oauth2 due to the use of access tokens.
  • In fact, Google, Facebook, Twitter, Microsoft(in azure) supports Oauth2 Api as a recommended authentication mechanism. also, they have customized Api for their specific use case.
  • Both Two-legged (simple one) or Three-legged(complex one) flow can be used for security based on your requirements.

What’s More?

We are just beginning to explore REST API. we have to lot discuss from how to use OAuth2, generating Docs using NelmioApiDoc, RateLimiting Api to viability, and use of HATEOS.

Category(s) API Uncategorized UVdesk
. . .

Leave a Comment

Your email address will not be published. Required fields are marked*

Be the first to comment.