A few days ago, techPortal published my tutorial Create a RESTful API with Apigility.
Apigility was announced at ZendCon US in October 2013 and I think that it looks like a useful tool for creating APIs. I particularly like that versioning is built in from the start and that it handles content negotiation.
If you want to learn about Apigility, then have a read. The source code is available on GitHub.
This is one of those posts to remind me how I solved a problem last time!
I've recently been using Capistrano for deployment and other remote tasks and it's proving quite useful.
One problem I ran into was that the umask was being set to 022 when using Capistrano and 002 when I was ssh'd into the server itself.
After a bit of research, I discovered that the secret is to put the umask statement in my .bashrc file before the line that says [ -z "$PS1" ] && return as when Capistrano logs into the server, it doesn't have an interactive shell (and so $PS1 isn't set.
My .bashrc now looks like this:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
(This is on Ubuntu 12.04 LTS)
I currently use a very simple set of core objects within my model layer: entities, mappers and service objects.
Entities are objects that represent something in my business logic. For example, in my traditional Album's tutorial, the entity would be the object that holds one album. It has properties such as title, artist and date created and methods that are specific to this entity.
Mappers know how to save and load an entity from the data store. This could be a database or a web service or an CSV file on disk. There is no requirement that a given entity maps to a single database table (or file on disk) as the mapper can simply use multiple tables for different properties within the entity if it wants to. The entity has no knowledge of how it is loaded and saved. This isolation means that I can have multiple mappers for the same entity that store it to different data stores.
Service objects provide the API that the rest of the application uses. I allow controllers and view helpers to talk to service objects, though I appreciate that others have a different take on MVC. Any given service object knows about mappers and entities and anything else that the business logic requires. I like having a service object as I can rework which mappers do what without having to touch the rest of the application. The service layer also know about other app details such as sending emails after a form is submitted. In an event based system, such as a ZF2, these details can now live in their own objects which listen for events triggered by the service object.
I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.