News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

ClanCats Station:
Writing a webserver in pure PHP - Tutorial
March 26, 2015 @ 11:27:42

On the Clancats.com blog there's a recent post showing how to create a web server in pure PHP, an interesting experiment but definitely not recommended for any kind of higher load situation.

Well, this is pretty useless, but it is possible. But again its pretty.. uesless. This tutorial will hopefully help you to better understand how a simple webserver could work and that it's no problem writing one in PHP. But again using this in production would be trying to eat a soup with a fork. So just, .... just don't. Let me shortly explain why this is not a that good idea.

PHP is a scripting language that simply is not really designed for such tasks. A webserver is a long running process which PHP is not made for. Also PHP does not natively support threading ( pthreads ), which will make developing a good performing webserver a really hard task.

He walks you through all the code needed to create the web server (also available on GitHub) by making:

  • A "server" that does the listening for incoming and sends outgoing requests
  • A request object that parses the incoming request and makes header and body content available
  • A response object that allows for the setting of response codes, body content and headers
  • Exception handling for problems encountered during the request/response process

The full code is provided during the process along with explanations of what each part does. There's also a basic introduction to what a typical web server is and how the process of request/response usually flows.

0 comments voice your opinion now!
webserver tutorial version request response server

Link: http://station.clancats.com/writing-a-webserver-in-pure-php

Evert Pot:
PSR-7 is imminent, and here's my issues with it.
March 04, 2015 @ 09:26:37

Evert Pot has written up a new post today with some of his thoughts about what's wrong with the PSR-7 proposal in the PHP-FIG. PSR-7 relates to a standardized interface for HTTP request and response handling.

PSR-7 is pretty close to completion. PSR-7 is a new 'PHP standard recommendation', put out by the PHP-FIG group, of which I'm a member of. [...] PSR-7 gets a lot of things right, and is very close to nailing the abstract data model behind HTTP, better than many other implementations in many programming languages.

But it's not perfect. I've been pretty vocal about a few issues I have with the approach. Most of this has fallen on deaf ears. I accept that I might be a minority in feeling these are problems, but I feel compelled to share my issues here anyway. Perhaps as a last attempt to sollicit change, or maybe just to get it off my chest.

He breaks up his thoughts into a few different categories, each with a summary and sometimes some code to help make his point a bit more clear. He talks about immutability, how objects will be immutable and shows an example of change in how Silex would have to function to follow the standard (with before/after). He then goes on to talk about the "issue with streams" and how the current proposal could allow for changing of the incoming request into a new one with new headers...not immutable. He ends the post talking about PSR-7's stance on buffering responses and how, even if his project doesn't adopt the PSR in the strictest sense, they may still take some inspiration from it.

0 comments voice your opinion now!
psr7 issues opinion phpfig http standard request response

Link: http://evertpot.com/psr-7-issues/

SitePoint PHP Blog:
API Client TDD with Mocked Responses
February 19, 2015 @ 12:57:51

The SitePoint PHP blog has posted the third part of their series guiding you through the creation of your first PHP package with a look at mocking API responses in unit tests created via the TDD (test-driven development) process.

In parts one and two, we built some very basic functionality and used TDD with PHPUnit to make sure our classes are well tested. We also learned how to test an abstract class in order to make sure its concrete methods worked. Now, let's continue building our library.

He starts with a bit of catching up to ensure everyone is on the same page in the development process. From there he starts in on the mocking of the API, preventing the need for the (slow) external requests. He shows some updates that are needed to the main DiffBot class, the factories/entities for making objects for requests and examples of putting these to use in a few tests. Finally he shows the creation of the mocks themselves and the result from a sample test.

0 comments voice your opinion now!
mock response tutorial unittest testdrivendevelopment api client

Link: http://www.sitepoint.com/api-client-tdd-mocked-responses/

Matthew Weier O'Phinney:
PSR-7 By Example
January 29, 2015 @ 09:13:20

As a part of his involvement in the PHP-FIG standards group, Matthew Weier O'Phinney has been contributing to the PSR-7 proposal. This proposal defines a standardized structure for HTTP message handling. In his latest post he gets into a bit more detail on what this means for the PHP developer and how it might be implemented.

PSR-7 is shaping up nicely. I pushed some updates earlier this week, and we tagged 0.6.0 of the http-message package last week for implementors and potential users to start coding against. I'm still hearing some grumbles both of "simplify!" and "not far enough!" so I'm writing this posts to demonstrate usage of the currently published interfaces, and to illustrate both the ease of use and the completeness and robustness they offer.

He starts with a base definition of what the proposal, well, proposes around HTTP messaging, both the incoming and outgoing. He describes the basic structure of an HTTP message and what each part represents. He talks about message headers, bodies and how the current library could return that content. He then looks at requests vs responses, server-side requests and some various uses cases and more practical examples:

  • HTTP Clients
  • Middleware
  • Frameworks

With the PSR-7 standard in place, all of these different tools could have interchangeable interfaces for HTTP request/responses, easily swappable with any other implementation.

0 comments voice your opinion now!
psr7 http message request response summary tool framework middleware client

Link: https://mwop.net/blog/2015-01-26-psr-7-by-example.html

Anthony Ferrara:
A Point On MVC And Architecture
December 02, 2014 @ 12:10:24

Anthony Ferrara has posted another in his series looking at MVC as a design pattern and as an idea for building web applications. In this latest post he goes on to make a point about MVC, how it relates to architecture and CRUD.

Last week I post a post called Alternatives To MVC. In it, I described some alternatives to MVC and why they all suck as application architectures (or more specifically, are not application architectures). I left a pretty big teaser at the end towards a next post. Well, I'm still working on it. It's a lot bigger job than I realized. But I did want to make a comment on a comment that was left on the last post.

He responds to the comment (essentially that CRUD is a solved problem) and where the need for customizations is needed. He suggests what the real problem is, though: the three classes of developers - CMS users, custom developers and users of both.

0 comments voice your opinion now!
mvc architecture opinion problem crud comment response

Link: http://blog.ircmaxell.com/2014/12/a-point-on-mvc-and-architecture.html

Phil Sturgeon:
Is PSR-0 Shortsighted, or are you?
April 17, 2013 @ 09:14:42

In a response to this previous post about the PSR-0 standard and why it might be "shortsighted", Phil Sturgeon has posted some of his own thoughts on the matter as a participant (and supporter) in the PHP-FIG group.

One of the fun things about trying to support the PHP-FIG and all the good its doing, is seeing blog posts written complaining about it by people that just don't know what they're talking about. I get involved in conversations on Reddit (dangerous I know) on a mission to understand the problems with its perception throughout the community, and try to make more knowledge readily available to avoid confusion. I put together the PHP-FIG FAQ and the rest of the group voted it in, which I believe helped a lot. Sadly some blog posts are sent out by people with a whole bunch of odd opinions that you just can't do anything about, so instead I'm going to respond with a play-by-play approach.

He goes through several of the points Tom made in his original post, pointing out places where the information was either misconceptions or just completely incorrect. He relates some of the autoloading suggestions Tom made back to things Composer can do and how this is different from "magic" on the part of the library user.

PSR-0 has its problems, but they are the two that I have pointed out and they are rather trivial. [...] If you'd like to add custom autoloaders to your Composer packages then go ahead. If you'd like to build your own custom autoloaders for all of your packages then you can do that too, but it ruins the entire purpose of what PSR-0 is meant to do. That's fine, because you don't need to use it, but I am happy as hell that PSR-0 exists and I wouldn't make drastic changes to it for anything.
0 comments voice your opinion now!
psr0 autoload opinion response phpfig composer

Link: http://philsturgeon.co.uk/blog/2013/04/is-psr0-shortsighted-or-are-you

NetTuts.com:
HTTP The Protocol Every Web Developer Must Know - Part 1
April 09, 2013 @ 10:56:28

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

0 comments voice your opinion now!
http protocol series basics headers statuscode verb request response

Link: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/

Hari KT:
Aura.Http Request and Response
February 18, 2013 @ 11:49:58

On his blog today Hari KT has an Aura Framework-related post about one of its components, the Aura.Http component, and its handling of HTTP requests and responses.

The Aura.Http package provide you the tool to build and send request and response. [...] Probably you may not have bothered too much on building the http response either the framework does it for you, or until you need to send the correct response.

The post shows you how to use the component to send and receive HTTP requests. Code is included showing how to make Response objects and set headers, content, cookies and HTTP response code. He also shows how to output the response and a more complete example of the entire flow. The post finishes up with an example of using Aura.Http to make a request to another site - in this case back to GitHub to get the users on a repository.

0 comments voice your opinion now!
aura project framework http request response tutorial


Lorna Mitchell:
How NOT to Design Your API
January 10, 2013 @ 10:46:04

Recently Lorna Mitchell asked the wide world of Twitter about some of their recommendations of things not to do when creating an API. In this new post to her site, she gathers together those responses including comments about documentation, consistency and response codes.

Recently I tweeted as a #linktuesday link the 10 Worst API Practices post from ProgrammableWeb. Today, in search of some concrete examples of APIs implementing unhelpful antipatterns, I sent out a tweet for help: "What's the most frustrating inconsistent/misleading bit of API you've seen? Looking for cautionary tales!" [...] In the raft of responses (and thankyou all, this was fabulous, helpful and entertaining in equal parts!), there were some definite patterns that I'd like to share with you, in no particular order.

Comments came in from all over and talked about things like:

  • Response codes not matching the content (ex. 200 on an error)
  • NullPointerExceptions
  • Different endpoints for single vs collections
  • Order-sensitive XML in requests
  • Poor error handling
  • Bad documentation
  • Incorrect content type handling
So there you have it, the sins to avoid in your own APIs. If you've encountered any of these, please accept my condolences.
0 comments voice your opinion now!
api design response code error handling documentation opinion twitter


Phil Sturgeon:
Arguing on the Internet
December 28, 2012 @ 10:51:39

In his latest post Phil Sturgeon shares some thoughts in response to this article from Shawn McCool about the "death of CodeIgniter", citing a few specific points.

I have referenced Shawn McCool's blog a few times, "Why CodeIgniter is Dead" and people are wondering why I argued so hard against it back in May but then gave CodeIgniter such a hard time in my last article. For the record I'm not team CodeIgniter or team Laravel, I'm a PHP user who has some opinions, and some of those opinions change over time - which is fair enough.

He goes through several of Shawn's points including:

  • Comments about best practices in CI (or lack of)
  • Modularity/design pattern use
  • The implementation of modules/sparks
  • The community contributions to the Reactor project
  • Dropping PHP4 support

Phil also notes that, just because something isn't making significant progress, it doesn't mean it's dead in the water:

Dead insinuates being closed right down. Repo removed, or just nothing is ever tagged again. Where CodeIgniter sits is closer to Smarty. Smarty is still active and has it's last stable release 2 months ago. It just hasn't changed much in years and probably never will.
0 comments voice your opinion now!
codeigniter opinion project response framework



Community Events

Don't see your event here?
Let us know!


series opinion performance extension podcast community library example interview introduction php7 voicesoftheelephpant framework symfony2 version laravel api application release conference

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework