Michael Mikowski has a post to his site that suggests that a RESTful API is a big lie and that the concept should "rest in piece" and be replaced with something he calls a "JSON-pure API".

If you have read an internet developer resume or job posting in the past 10 years, then you might be forgiven if you think that RESTful APIs are gifts bestowed from the heavens by The One True Web Developer Deity. RESTful APIs are everywhere. Even the marketing folks are pushing them in sales material intended for CEOs and Human Resources-type folks. So how good of an idea are RESTful APIs really?

He starts with a look at where the concepts for a RESTful API originally came from and defines some of the most common concepts around them (verbs, request/response, etc). He then suggests that they're "pretty awful" and lists some of the larger problems he sees with them:

• Problem #1: There is little agreement on what a RESTful API is
• Problem #2: The REST vocabulary is not fully supported
• Problem #3: The REST vocabulary is not rich enough for APIs
• Problem #4: RESTful APIs are very hard to debug
• Problem #5: RESTful APIs are usually tied to HTTP

He suggests that the way to move forward is to migrate to the "JSON-pure API" methodology, fixing most of the problems he listed. He describes this kind of API and how it simplifies the entire process and makes it "more reliable, easier to use, easier to port, and easier to debug."

On the Ibuildings techPortal today they've posted the latest episode of their recording series from last year's Dutch PHP Conference (DPCRadio) - Sebastian Bergmann's talk The Cake is a Lie.

Scaffolding, the meta-programming method of building software applications, promises easier development and a faster time-to-market. But the "code generation bliss" can lead to problems later on, for instance with regard to maintainability and scalability. This sessions takes a skeptical look at frameworks such as CakePHP and symfony.

You can listen in one of three handy ways - either by listening in-page, downloading the (rather large) mp3 or by subscribing to their feed to get this and other great techPortal content.

If you think you know what's going on behind the scenes when you're working with objects in PHP5 - you're wrong. You're even being lied to, according to Sara Golemon's latest entry:

If you're among the crowd who have migrated an OOP based application from PHP4 to PHP5, then I'm sure you've heard the expression "Objects are copied by reference by default in PHP5". Whoever told you that, was lying.

As she explains, the truth is more that they behave that way, not that they are actually like that. She talks about what objects actually are and how things are handled differently from PHP4 to PHP5. She also "lies" a little also about the "copying" part, and explains the internal structure of a variable to show why.

She also includes a bit on why referencing variables when it's not really a must is a bad idea - the main idea of it being a waste of space and memory in the application.

If you think you know what's going on behind the scenes when you're working with objects in PHP5 - you're wrong. You're even being lied to, according to Sara Golemon's latest entry:

If you're among the crowd who have migrated an OOP based application from PHP4 to PHP5, then I'm sure you've heard the expression "Objects are copied by reference by default in PHP5". Whoever told you that, was lying.

As she explains, the truth is more that they behave that way, not that they are actually like that. She talks about what objects actually are and how things are handled differently from PHP4 to PHP5. She also "lies" a little also about the "copying" part, and explains the internal structure of a variable to show why.

She also includes a bit on why referencing variables when it's not really a must is a bad idea - the main idea of it being a waste of space and memory in the application.