Today I released a new package called laravel-fractal. It provides a Fractal service provider for Laravel. If you don't know what Fractal does, take a peek at their intro. Shortly said, Fractal is very useful to transform data before using it in an API. Using Fractal data can be transformed like…
When we built Facebook's mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple enough to be easy to learn and use by our product developers. We developed GraphQL three years ago to fill this need. Today it powers hundreds of billions of API calls a day. This year we've begun the process of open-sourcing GraphQL by drafting a specification, releasing a reference implementation, and forming a community around it at graphql.org.https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-language/
There's already a package to use GraphQL with Laravel.
Join 9,500+ smart developers
Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
"As a Laravel developer, this is the one newsletter I most look forward to. Freek has a talent for distilling packages or techniques down to something immediately useful - one tip can save you hours and even weeks. It's concise and practical and highly relevant."
V2.0 of the API was a weird hybrid of RESTful and RPC practices, which required everyone to learn our own special style of API design. With a few minor exceptions, API v3.0 is fully RESTful. This allows us to express in a couple dozen resources what it took the last version 120 distinct endpoints to accomplish.http://devs.mailchimp.com/blog/api-v3-0-officially-launched/
Consuming this API doesn't seem to be that hard but I hope they'll release a PHP wrapper soon.
... it’s important to remember that API design isn’t strictly about the practical implications on client and server software. The audience for an API is the developer who is going to consume it. Per the "principle of least astonishment," developers will have an easier time learning and understanding an API if it follows the same conventions as other APIs they’re familiar with.https://blogs.dropbox.com/developers/2015/04/how-many-http-status-codes-should-your-api-use/
Having documentation on your API is highly beneficial. If it is well written you're likely going to receive less questions by consumers of your API about how it works.
Aglio is a nice tool that I've been using to generate API documentation. In goes the Markdown, out comes the beautiful documentation.
Google introduced a new method that verifies you are human without you having to solve a riddle.
On websites using this new API, a significant number of users will be able to securely and easily verify they’re human without actually having to solve a CAPTCHA. Instead, with just a single click, they’ll confirm they are not a robot.
It looks like this:
http://googleonlinesecurity.blogspot.nl/2014/12/are-you-robot-introducing-no-captcha.html
