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:
(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:
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.
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:
Besides learning a frameword like Laravel, you have to learn a micro framework as well
Building an API in Lumen for example, is often harder then making it in Laravel
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?
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.
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 send me an
Or Visit my website.
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"
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!
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.
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.
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: