Evert PotDropbox starts using POST, and why this is poor API design. (2.3.2015, 21:12 UTC)

Today Dropbox announced in a blogpost titled "Limitations of the GET method in HTTP" that it will start allowing POST requests for APIs that would otherwise only be accessible using GET.

It's an interesting post, and addresses a common limitation people run into when developing RESTful webservices. How do you deal with complex queries? Using URL parameters is cumbersome for a number of reasons:

  1. There's a limitation to the amount of data you can send. Somewhere between 2KB and 8KB apparently.
  2. URL parameters don't allow nearly enough flexibility in terms of how you can define your query. The percent-encoded string doesn't really have a universal way to define in what character set its bytes are,
  3. The URL is not nearly as versatile and expressive as JSON, and let alone XML.

Their solution to this problem is to now allow POST requests on endpoints that traditionally only alowed GET.

Is this the best solution? Well, it's certainly a pragmatic one. We're clearly running into artificial limitations here that are poorly solved by existing technology.

The problem with POST

Switching to POST discards a number of very useful features though. POST is defined as a non-safe, non-idempotent method. This means that if a POST request fails, an intermediate (such as a proxy) cannot just assume they can make the same request again.

It also ensures that HTTP caches no longer work out of the box for those requests.

Using REPORT instead

The HTTP specification has an extension that defines the PATCH request, this spec is picking up some steam, and a lot of people are starting to use it to solve common problems in API design.

In the same vein, there's been another standard HTTP method for a while with the name REPORT, which specifically addresses some of the issues with POST.

The REPORT request:

  1. Can have a request body
  2. Is safe
  3. Is idempotent

It appears in the IANA HTTP Method list and is actually quite great for this use-case. The main reason it's off people's radar, is because it originally appeared in a WebDAV-related spec a long time ago.

However, its semantics are well defined and it works everywhere. I would love to see more people start picking this up and adding it to their HTTP API toolbelt.

Using GET with a request body

Whenever this topic comes up on Hacker News, there's almost guaranteed to be a comment about using GET with a request body.

I wondered about this myself (6 years ago now apparently!) and it's my top question on stackoverflow. Clearly a lot of people have the same thinking process and wonder about this.

Using a request body with GET is bad. It might be allowed, but it's specifically defined as meaningless. This means that any HTTP server, client or proxy is free to discard it without altering the semantic meaning of the request, and I guarantee that some of them will.

Furthermore, the benefits of using GET are then completely gone. Caching is not based on request bodies, and these requests are not addressable with a URI.

Literally the only reason why anyone would do this is because GET looks nicer, it's an aesthetic decision, and nothing more.

Why real GET requests are great: addressability

Whether you use POST or the superiour REPORT request, you still miss the biggest advantage of using GET requests.

A GET query is always a URI. Anyone can link from it. Parts of your service can link to specific results. Even external services can integrate with you by referring to specific reports.

A POST query can not be linked and neither can a REPORT query. All we can do is explain that a certain URI accepts certain http methods with certain media-types, but this is not nearly as elegant as a simple URI. Linking rocks.

An alternative approach

One way to solve this issue entirely and fix all problems related to this, is disconnect the query you are doing from its result.

To do this, you could create a /queri

Truncated by Planet PHP, read more at the original (another 1289 bytes)

Nomad PHPMay 2015 – US (2.3.2015, 19:32 UTC)

An In-depth Look at Slim Framework 3.0

Presented By
Josh Lockhart
May 21, 2015 20:00 CDT

The post May 2015 – US appeared first on Nomad PHP.

Paul M. JonesBookdown: DocBook-Like HTML Output From Markdown (2.3.2015, 17:04 UTC)

From bookdown.io:

Bookdown generates DocBook-like HTML output using Markdow> n and JSON files instead of XML.

Bookdown is especially well-suited for publishing project documentation to > GitHub Pages.

Features include:

  • Automatic table-of-contents generation as index pages at each hierarchy level

  • Custom index-page titles via JSON configuration

  • Automatic numbering of page headings

  • Automatic previous/next/up navigation headers and footers

  • Multi-page hierarchical output

  • Loading of remote content files via HTTP

  • Templated output for theming

  • Overridable page processing, especially for rendering

Bookdown can be used as a static site generator, or as a way to publish static pages as a subdirectory in an existing site.

Yes, I know, there’s a ton of static site generators for PHP out there already. Sculpin seems to be the big one (hi Beau!) but it’s not specifically for documentation. Then there’s Couscous (hi Matthieu!), which is for documentation, but it’s not DocBook-like documentation.

By “DocBook-like”, I mean (among other things) numbered headers, auto-generated tables-of-contents on their own pages, hierarchical multi-page presentation, and the next/previous/up linking at the top and bottom of pages. Look at the Solar documentation sites for a better idea; the content on those pages was generated with DocBook.

And frankly, look at the dependency listings on those two projects (Scuplin, Couscous). They’re rather extensive. It that a bad thing? No, but it’s not my speed. I think we we all know at this point that I’m about reducing dependencies as much as possible, and those are just too much for me.

Also: I can’t stand YAML. I don’t like YAML embedded in pages, and I don’t like YAML config files. I much prefer JSON, and I don’t want to add YAML frontmatter on Markdown pages.

So: Bookdown. This scratches my particular itch, with very few dependencies.

Bookdown, although it can be used as a site generator, is only incidentally a site generator. What it really is is a page generator, with the idea that you can integrate the pages into any other site you want.

Additionally, Bookdown allows you to pull content from remote locations. This is especially interesting to me because of the decoupled nature of Aura libraries. I would like very much to keep the manual documentation on each library in the same repo as that library, then publish each alone, and as part of a collection, without having to copy files around. Bookdown remote content should allow for that.

I’m happy with the architecture as well. It took two weekends of experimenting, and then almost exactly a week of dedicated development, to build Bookdown.

The library is fully separated from the project. That means you can either run it as a project on its own, or integrate the core library into your own project and glue its services and commands into your own work.

Everything uses dependency injection through an application-specific container which helps to keep the concerns well-separated. Everything uses factories and builders, which helps to enable the dependency injection.

All the underlying processes are decoupled from each other, which should make it easy to replace them with custom processes. For example, the ConversionProcess currently uses CommonMark, but I find it easy to imagine end-users replacing that with Textile, ReStructuredText, or even a combination of conversions that examines the filename extension.

Finally, the code style is a little bit of a departure for me as well. I have previously used $snake_case variables, b

Truncated by Planet PHP, read more at the original (another 511 bytes)

SitePoint PHPBuilding APIs You Won’t Hate: Review (2.3.2015, 17:00 UTC)

This is a review of Phil Sturgeon’s book Build APIs You Won’t Hate.

Build APIs You Won’t Hate

A bit of an edgy title, isn’t it? It makes sense, though. The potential of a developer hating anything he built given enough time to work on it is enormous. It’s an inverse parabola of sorts - your enthusiasm will grow for a given amount of time, and then proportionally drop until you sink below the starting point of pleasure. If you push through this depression, learn new techniques, and then apply them to your work you get a kind of sine wave in which your enthusiasm again rises until it starts dropping, and so on and so forth.

Continue reading %Building APIs You Won’t Hate: Review%

Davey ShafikZend Certification Study Guide 3rd Edition Published, and a new Book on the way! (1.3.2015, 16:00 UTC)

After many months of work, a couple of weeks ago php[architect] published the 3rd edition of the Zend Certification Study Guide.

Zend Certification Study Guide

I am really proud of this edition, which has been updated completely up to PHP 5.6 (the certification is currently up to 5.5), making it a great desk reference for everything new in PHP.

It includes 3 new chapters, and 2 new appendices, including one on the new debugger added in PHP 5.6, phpdbg — that’s over 80 pages of new content.

All of the new additions indicate which version they were added in, and based on a comprehensive scouring of the NEWS file, I am confident that anything worth mentioning as new in PHP has been included.

Additionally, I just announced a new project of mine, The Definitive Guide to PHP and MySQL. This is intended to be a comprehensive, in-depth book on vanilla PHP and MySQL.

The Definitive Guide to PHP and MySQL

It will cover everything from SQL basics, to MySQL Native Driver, making it ideal for all skill levels, and hopefully turning even the most novice user into an accomplished developer.

This book will be published via Leanpub, and I will start making it available as soon as I have some of the beginning chapters completed — currently it’s about 30-35% complete, but the majority of it is intended to end up towards the end of the book.

If you are interested in this book, please show your support by filling out the form — this is crucial for me to gauge interest and pricing.

SitePoint PHPBest PHP Framework 2015 Survey (27.2.2015, 17:00 UTC)

Almost a year and a half ago we published the results of a framework survey on the PHP channel. The survey, while producing fewer entries than our IDE survey still provided us with valuable insight into our audience and the state of individual vs. team developers out there.

With Laravel 5 fresh out of the oven, Phalcon being kickstarted into full-time development, and others reaching a much anticipated maturity, it’s only natural we’re curious about your preferences - have they changed? Do they remain unbudged? Do you wish you could switch so hard you can taste it, but aren’t allowed to by your company? We’re interested in all these points and much more.

Continue reading %Best PHP Framework 2015 Survey%

Derick RethansXdebug 2.3: Moar var_dump() (27.2.2015, 08:57 UTC)

Xdebug 2.3: Moar var_dump()

This is the first article in a series about the new features in Xdebug 2.3, which was first released on February 22nd.

One of the new features relates to one of the first things that I added in the original Xdebug: making the var_dump() output "pretty". Xdebug replaces PHP's standard var_dump() function with its own version, as long as the xdebug.overload_var_dump setting is not set to 0.

Which means that instead of:

array(4) { [0]=> int(42) [1]=> string(6) "string" [2]=> bool(true) [3]=> float(3.1415926535898) }

You get:

Nothing new so far.

Xdebug 2.3 enhances the overloading of var_dump() with the inclusion of the file name and line number where var_dump() is called at. This has been a long standing feature request.

You can include this information, by setting xdebug.overload_var_dump to 2. If the xdebug.overload_var_dump setting is set to 2, the overloaded var_dump() output now looks like:

As you can see, the file name and line number of where var_dump() were called are prepended to the output.

An already existing setting, xdebug.file_link_format, allows you to format file name and line number information so that Xdebug generates a link. This same setting is also respected by the inclusion of the file name and line number in the enhanced var_dump() output. Setting xdebug.file_link_format to xdebug://%f:%l will then link the file name to xdebug:///home/httpd/html/test/xdebug/overload-var-dump.php:4. If we look at this as an image, we will see:

In a future version of Xdebug, it is likely that I will either wrap in the file name/line number information in the overloaded var_dump(), or change the default value of the setting to 2.

Ilia AlshanetskyPHP Excel v1.0.1 Released (26.2.2015, 16:12 UTC)
The long awaited v1.0.1 of PHP-excel extension is finally out, lots of changes in this one.
You can download the source code at: https://github.com/iliaal/php_excel/archive/1.0.1final.tar.gz
the Github repo is available at: https://github.com/iliaal/php_excel

Full ChangeLog is Below:

Continue reading "PHP Excel v1.0.1 Released"
thePHP.ccConFoo 2015: It's that time again (26.2.2015, 07:00 UTC)
Nomad PHPKeeping the Code Monkey Fit (25.2.2015, 19:13 UTC)

Speaker: Rebecca McGrane @RebeccaMcGrane 30 seconds can end backaches, neck strain, eye fatigue carpal tunnel and other common pains of being a full time programmer, or as I lovingly call mine Code Monkey. In 10 minutes I will share everything you need to know to stop pain, improve your cardiovascular health, boost brain cells (AKA …

The post Keeping the Code Monkey Fit appeared first on Nomad PHP.

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP