NYCPHP Meetup

[Paul A Houle]

Matt Juszczak wrote:
>>   The term "REST" is an early predictor for project failure a year or 
>> two down the road.  More than once I've been the guy who cleans up 
>> the mess after somebody ignorantly blunders into using "REST" for 
>> something that it's not appropriate for.
>
> Well, we didn't go that route.  We had three choices: Put database 
> logic inside the webserver code base, put it in the database, or put 
> it somewhere in the middle.  We decided on putting it in the database, 
> which ties us to using MySQL, but allows us to write a lot more front 
> ends a lot easier.
>
    The architecture where "multiple processes communicate with a shared 
database" gets less credit than it deserves.  In your case I think 
there's no reason you can't write your batch scripts in PHP:  pretty 
commonly I write command line scripts that run as cron jobs...  In that 
situation,  you can use

http://php.net/manual/en/function.pcntl-fork.php

    to fork the same way you would in Perl.  I tend to do long-running 
tasks as cron jobs that are scheduled to run for a certain time (maybe 4 
minutes) and that get respawned every so often (say 5 minutes.)  You do 
need some logic to prevent them from getting stacked up when things go 
wrong,  but this works pretty well.

    BTW,  I've got no problem with an RPC-based architecture;  there 
really are two ways REST is a danger sign:  (i) 80% of the time it's a 
sign that people don't know what they're talking about...  They really 
want to say "not SOAP" and they've never heard of POX (plain old XML) or 
POJ (plain old JSON.)  In those cases it's easy to set people straight.  
The 20% of people (ii) who know what REST are actively dangerous.

    There are quite a few problems w/ REST,  but the biggest is the lack 
of transactional semantics.  It's easy to write a RPC that "transfers 
money from bank account A to bank account B" and handles all the 
transactional stuff on the server side.  Now,  it's certainly possible 
to build a REST system that posts a transfer slip,  and the posting of 
the transfer slip causes the transfer to happen transactionally;  that 
could be part of a great document-based architecture,  but I've yet to 
see somebody using REST in the field think that far ahead.  I suppose 
you could use REST together with a distributed transaction mechanism,  
but that's really asking for trouble.