GraphQL: A data query language

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.

Read more

MailChimp API v3 is officially launched

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.

Read more

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.

How many HTTP status codes should your API use?

... 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/

Read more