On the 9Lessons.info site they've posted a tutorial walking you through the creation of an application using Iconic 3, Angular 4 and a PHP restful API and how to handle user authentication and signup. It's a continuation from this previous post that kicked off the series.

Today’s post explains how to implement login authentication system for your AngularJS applications. It will show you how to log in with a user and store the user session, so it deals with token based authentication. Since we are using token based authentication, it protects if any unauthorized request is made and notices for a new login if required. This makes your application’s authentication to be more secured compared with any other authentication system. Every user details will be stored in an external database and a PHP based API is used in the backend for handling this authentication. Hope you’ll find it more easily using this as your authentication system in your AngularJS projects.

They assume you've worked through the previous post and already have the basic structure of the application set up. They share a screencast showing the process but also include the key details - database tables, code and markup - in the post for those that prefer to follow along that way.

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

Michael Dowling has announced the release of Guzzle 4.0.0 on his site today. Guzzle is one of the most widely used, popular HTTP clients in the PHP community today. Its used in both corporate and open source projects as a primary means for making HTTP requests and RESTful web service clients.

Guzzle 4.0 has arrived! The new version of Guzzle is now simpler, faster, more flexible, and more powerful than ever. [...] Guzzle is a PHP HTTP client that makes it easy to work with HTTP/1.1 and takes the pain out of consuming web services.

He includes a quick example of it in use making a request to the GitHub API to fetch user information. He lists out some of the changes made in this release but points to this other post for the full list. He's also tagged other related projects to match this 4.0.0 release including Guzzle Streams and the Log Subscriber.

Matthew Weier O'Phinney has posted the first part of a new series he's been working on about creating RESTful APIs with the help of Zend Framework v2. In this part, he looks at things like the "Richardson Maturity Model" and "Hypertext Application Language" as parts of development of the API too.

RESTful APIs have been an interest of mine for a couple of years, but due to circumstances, I've not had much chance to work with them in any meaningful fashion until recently. Rob Allen and I proposed a workshop for PHP Benelux 2013 covering RESTful APIs with ZF2. When it was accepted, it gave me the perfect opportunity to dive in and start putting the various pieces together.

After going over the "Richardson Maturity Model" for the REST structure he spends the rest of the post looking at HAL ("Hypertext Application Language") structure and examples. He mentions the media types it uses, how it handles links between resources and how to embed a resource into the resulting response.

On NetTuts.com today they've posted the start of a new series looking at the creation of a RESTful API with the help of the Laravel 4 framework (in beta at the time of this post).

RESTful API's are hard! There are a lot of aspects to designing and writing a successful one. For instance, some of the topics that you may find yourself handling include authentication, hypermedia, versioning, rate limits, and content negotiation. Rather than tackling all of these concepts, however, let's instead focus on the basics of REST. We'll make some JSON endpoints behind a basic authentication system, and learn a few Laravel 4 tricks in the process.

Their API example is a "read it later" kind of application where users can store links to URLs they want to read later. They walk you through the installation of the framework, creation/configuration of the database and include the migrations to set it up. From there they help you set up the models, some authentication and routing. Finally, they get to the controllers and the functionality of the application, creating the URL controller to handle the creation, listing and updating of the resources.

Lorna Mitchell has posted a quick checklist of things you can ask about your API to see if it's RESTful or not (five of them):

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. [...] A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

• It has a single endpoint
• All requests are POSTs
• Response metadata is in the body, not header
• There are verbs in the URL
• The URL includes method names

She suggests, though, that "being RESTful" isn't a requirement for "being useful" when it comes to APIs.

Lorna Mitchell is back with another post in her "Building a RESTful PHP Server" series today with this new post showing how to work with output handlers (her focus is on JSON).

So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

She advocates using output handlers instead of the usual views you'd think of in a typical MVCish sort of application. The difference here is that there's not a lot of extra overhead to produce the results - it's literally an output directly from a class extending the base view (including the correct headers). She also briefly mentions the inclusion of JSONP functionality, allowing you to specify a local callback to execute when the request is returned. A few other "nice to haves" are also mentioned like the number of results returned and pagination support.

Lorna Mitchell is back with a second installment in her "Building a RESTful PHP Server" series with this new post about handling and routing the incoming requests. (You can find the first part about working with the request here)

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

In this new post to her blog Lorna Mitchell starts off a new series (based on popular demand) looking at building an RESTful server in PHP. Back to basics - no framework, just PHP.

In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved.

Her "basics" include:

• the routing to send everything to the main index file (a "front controller" of sorts) with the .htaccess settings included
• Handling the incoming request with a "Request" class
• Parsing the incoming parameters from the "php://input" stream

New on PHPBuilder.com today is a tutorial introducing you to web services with the Zend Framework, a guide to creating a simple RESTful service with this popular PHP framework.

Rather than attempt to build and maintain multiple versions of the Web application in order to accommodate the diverse array of challenges and advantages presented by each device type, developers are increasingly embracing a unified approach which allows them to manage a single server-side code base which communicates with multiple client-specific interfaces by way of a RESTful Web service. The Zend Framework's Zend_Rest component offers PHP developers with an incredibly straightforward approach to building RESTful Web services.

He shows how to set up some internal RESTful routing (with the help of Zend_Rest_Route) and create a simple controller that responds to several of the major HTTP request types - POST, GET, PUT, etc. In his simple example, he shows how to update a basic TODO list with a POST and the JSON response that would follow.