RESTfulAPI.nl is your starting point when you are in need for a RESTful API
Our focus is RESTful API's made with Laravel and Lumen.
Please let us know if we are missing relevant RESTful PHP API's, - tutorials or - tools.
Mail us if you want us to build your RESTful API.
 





What is REST?

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

  • In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

  • Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture.

REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

 





How Simple is REST/ Is REST better then SOAP?

Let's take a simple web service as an example: querying a phonebook application for the details of a given user. All we have is the user's ID.

Using Web Services and SOAP, the request would look something like this:

<?xml version="1.0"?>
        <soap:Envelope
        xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
        soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
         <soap:body pb="http://www.acme.com/phonebook">
          <pb:GetUserDetails>
           <pb:UserID>12345</pb:UserID>
          </pb:GetUserDetails>
         </soap:Body>
        </soap:Envelope>

(The details are not important; this is just an example.) The entire shebang now has to be sent (using an HTTP POST request) to the server. The result is probably an XML file, but it will be embedded, as the "payload", inside a SOAP response envelope.

And with REST? The query will probably look like this:

http://www.acme.com/phonebook/UserDetails/12345

Note that this isn't the request body -- it's just a URL. This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data -- not embedded inside anything, just the data you need in a way you can directly use.

  • It's easy to see why Web Services are often used with libraries that create the SOAP/HTTP request and send it over, and then parse the SOAP response.
  • With REST, a simple network connection is all you need. You can even test the API directly, using your browser.
  • Still, REST libraries (for simplifying things) do exist, and we will discuss some of these later.

Note how the URL's "method" part is not called "GetUserDetails", but simply "UserDetails". It is a common convention in REST design to use nouns rather than verbs to denote simple resources.

The letter analogy
A nice analogy for REST vs. SOAP is mailing a letter: with SOAP, you're using an envelope; with REST, it's a postcard. Postcards are easier to handle (by the receiver), waste less paper (i.e., consume less bandwidth), and have a short content. (Of course, REST requests aren't really limited in length, esp. if they use POST rather than GET.)

But don't carry the analogy too far: unlike letters-vs.-postcards, REST is every bit as secure as SOAP. In particular, REST can be carried over secure sockets (using the HTTPS protocol), and content can be encrypted using any mechanism you see fit. Without encryption, REST and SOAP are both insecure; with proper encryption in place, both are equally secure.

See rest.elkstein.org
See Wikipedia



 





What is an API?

An application program interface (API) is code that allows two software programs to communicate with each other.



 





What is a RESTful API?

A RESTful API is an application program interface (API) that uses the REST principles.
"A REST API defines a set of functions which developers can perform requests and receive responses via HTTP protocol such as GET and POST. "



 





Which framework to use for your api?

A reason to use a micro framework like Lumer or Silex, instead of laravel or Symfony for example, is performance. In general, Micro frameworks are faster.
Disadavanteges of using a micro framework:
  1. Besides learning a frameword like Laravel, you have to learn a micro framework as well
  2. Building an API in Lumen for example, is often harder then making it in Laravel
  3. When the demands for your api grow, a micro framework might not be suffiencient anymore
With the speed of PHP 7, it is questionable, if the performance gain of a micro framework, outweighs it's disadvantages.
We have Laravel booting in 30ms, with PHP 7 and Opcache. Who needs more speed?

An interesting resource about this issue is "When To Deploy Micro-Frameworks or Full-Stack Frameworks"

The author of www.laravelista.com used both Laravel and Lumen, and has interesting observations on the choice of a framework:

When to use Lumen over Laravel

It took me a lot of workarounds to get things working with Lumen and JWT. It all started going downhill since the installation chapter. First the missing config_path function, then the vendor:publish command and then the illuminate/routing package.

I have managed to solve every issue that occurred and got the API working, but...

While I was writing this post, a friend of mine had an app idea and we agreed that I will write an API that is very similar to this one in the way that it uses Fractal and JWT tokens. The only difference is that I have decided to build it on Laravel 5.1.

Oh boy ... I cannot believe how much easier it was to create the same API (more advanced, with more API methods, more security, better validation) and in less time. Btw every error mentioned in this post was non existent on Laravel. It all went so smoothly and everything had just set in place.

This is the description on official Lumen website:

Lumen is the perfect solution for building Laravel based micro-services and blazing fast APIs.

Maybe this line could be a little miss guiding because of the blazing fast APIs. Mine first thought was that you are meant to build APIs with it, but once I read it one more time I got the impression that Lumen is primarily built for micro-services that in fact are small APIs. And this turns to be right. I think that one of the reasons why we don't see many tutorials on how to create an API with Lumen is because it is used for creating smaller APIs.

Don't get me wrong. If I have to write a small little API that does a thing or two and it needs to be faster I will use Lumen. But if you are building an API or something that will be the backbone of your entire application you are better off with Laravel.

Please give your opinion below  





How can a RESTful API be made?

A RESTful API van be made with a serverside scripting language like PHP. Using Laravel with PHP makes is more easy to build.
We can make a RESTful API for you. Please visit my website to contact me .  






Live RESTful API demo's

There are Lots of API tutorials, but hardly any live demo's. An example says more then a 1000 words, so we collected Laravel 5 API's and made them work, so you can see them in action.

Laravel backend with AngularJS frontend - "Employees"

See live demo


Laravel backend - "Schools API"

See tutorial


HTTP Method Route Corresponding Action
GET api/v1/laravel/schools App\Http\Controllers\SchoolsController@index See API response
GET api/v1/laravel/schools/create App\Http\Controllers\SchoolsController@create
POST api/v1/laravel/schools App\Http\Controllers\SchoolsController@store
GET api/v1/laravel/schools/{schools} App\Http\Controllers\SchoolsController@show
GET api/v1/laravel/schools/{schools}/edit App\Http\Controllers\SchoolsController@edit
PUT api/v1/laravel/schools/{schools} App\Http\Controllers\SchoolsController@update
PATCH api/v1/laravel/schools/{schools} App\Http\Controllers\SchoolsController@update
DELETE api/v1/laravel/schools/{schools} App\Http\Controllers\SchoolsController@destroy



"Jokes" API

This API uses "token based authentication", which is often the preferred way of authentication for API's.
For Token Based authentication, the laravel package called jwt-auth is used.
NOTE: this tutorial is not ready yet!

See tutorial

POST laravel/api/v1/authenticate App\Http\Controllers\AuthenticateController@authenticate Demo getting & storing token clientside
POST laravel/api/v1/authenticate App\Http\Controllers\AuthenticateController@authenticate Demo getting a token with jwt-auth
GET laravel/api/v1/jokes App\Http\Controllers\JokesController@index See API response
GET laravel/api/v1/jokes/create App\Http\Controllers\JokesController@create Demo CREATE
POST laravel/api/v1/jokes App\Http\Controllers\JokesController@store "
GET laravel/api/v1/jokes/{jokes} App\Http\Controllers\JokesController@show Demo SHOW
GET laravel/api/v1/jokes/{jokes}/edit App\Http\Controllers\JokesController@edit
PUT laravel/api/v1/jokes/{jokes} App\Http\Controllers\JokesController@update Demo PUT
PATCH laravel/api/v1/jokes/{jokes} App\Http\Controllers\JokesController@update Demo PATCH
DELETE laravel/api/v1/jokes/{jokes} App\Http\Controllers\JokesController@destroy



Laravel backend - basic-authentication - "Todo API"


See tutorial

User name: testtest
Password: testtest

HTTP Method Route Corresponding Action
GET laravel/basic-authentication/todo App\Http\Controllers\TodoController@index See API response
POST laravel/basic-authentication/todo App\Http\Controllers\TodoController@store



Laravel backend - basic-authentication - "Larashop API"

See tutorial

User email: jan@test.nl
Password: testtest

HTTP Method Route Corresponding Action
GET laravel/larashop/api/v1/products/{id?} Closure See API response
GET laravel/larashop/api/v1/categories/{id?} Closure See API response



Laravel backend - basic-authentication - "Simple API"

This is the most simple API we found.
See tutorial

User email: jan@test.nl
Password: testtest

HTTP Method Route Corresponding Action
GET laravel/names/api App\Http\Controllers\NameController@index See API response
GET laravel/names/api/create App\Http\Controllers\NameController@create
POST laravel/names/api App\Http\Controllers\NameController@store
GET laravel/names/api/{api} App\Http\Controllers\NameController@show
GET laravel/names/api/{api}/edit App\Http\Controllers\NameController@edit
PUT laravel/names/api/{api} App\Http\Controllers\NameController@update
PATCH laravel/names/api/{api} App\Http\Controllers\NameController@update
DELETE laravel/names/api/{api} App\Http\Controllers\NameController@destroy
 





RESTful API tools

Laravel and AngularJS Starter Application
This is a repo for a starter application for a Single Page Application featuring the modern Laravel PHP framework and Google’s acclaimed front-end framework AngularJS.
Just download and install and you have a good foundation for building any application.

Laravel package Dingo
A simple RESTful API is easy.
But when things like Rate Limiting, Multiple Authentication Adapters and Content Negotiation are needed, is gets more complicated.
A package like Dingo can save you time for those needs.

Postman for Chrome can be handy for testing your API.
With Postman you an easliy do oparations like POST and GET, so you don't have to make forms to test you API.

Fiddler, The free web debugging prox for any browser, system or platform

PHP-CRUD-API
Single file PHP script that adds a REST API to a MySQL database.

jwt-auth
jwt-auth provides a simple means of authentication within Laravel using JSON Web Tokens.

Tino Tkalec explains why "token based authentication", is often the preferred way of authentication for API's

Advantages of Token-Based Authentication

Advantages of Token-Based Authentication

Stateless, easier to scale: The token contains all the information to identify the user, eliminating the need for the session state. If we use a load balancer, we can pass the user to any server, instead of being bound to the same server we logged in on.

Reusability: We can have many separate servers, running on multiple platforms and domains, reusing the same token for authenticating the user. It is easy to build an application that shares permissions with another application.

Security: Since we are not using cookies, we don’t have to protect against cross-site request forgery (CSRF) attacks. We should still encrypt our tokens using JWE if we have to put any sensitive information in them, and transmit our tokens over HTTPS to prevent man-in-the-middle attacks.

Performance: There is no server side lookup to find and deserialize the session on each request. The only thing we have to do is calculate the HMAC SHA-256 to validate the token and parse its content.

 





Troubleshooting

Error "TokenMismatchException in VerifyCsrfToken.php"

Laravel expects a token for preventing cross-site request forgery(CSRF) when handling operations like POST and DELETE.
If no token is send, or the wrong token is send, this error is given.
Generally API's are used for cross site requests. So then CSRF protection is pointless.
This manuals explains how to remove CSRF protection for certain routes:

Modify the Handle function in app/Http/Middleware/VerifyCsrfToken.php to:

public function handle($request, Closure $next)
{
    //disable CSRF check on following routes
    $skip = array(
        'user/path/xys',
        'user/profile',
        'my/unprotected/route'
    );

    foreach ($skip as $key => $route) {
        //skip csrf check on route
        if($request->is($route)){
            return parent::addCookieToResponse($request, $next($request));
        }
    }
    return parent::handle($request, $next);
}
                            

 





Contact

Location

Westerpark, Amsterdam, Netherlands

Send an e-mail