According to the PHP Manual HTTP PUT is implemented as a sort of file upload emulation as though that was useful.
The whole subject of HTTP PUT was very murky until I read the RESTful Architecture O'Reilly book. What you need to know is that in a ROA (a Resource Orientated Architecture) uses HTTP PUT to create a resource.
Think social networking paths to individual resources requires a different function. In php it is analogous to:
HTTP PUT thing = make a file thing
You never want to make a file on a website. If you want a user to supply a resource this should be in a sequestered way, not in the actual pathways of the website.
With PHP there is a far more powerful way to implment HTTP PUT. First test that your brower is sending PUT and PHP is getting it.
Next, implement a resource appliction architecture that creates resources, not files. What is a resource? It is a set of objects you want to have exist on the server.
For example
GET /customer
returns a resource, in this case a list of customers
PUT /customer/1441
creates a resource, in this case customer 1411
PUT /customer/1411/name/Johnson
creates a customer whos name property is set to Johnson
Of course how a ROA is implemented in PHP is slightly different from the PHP manaul.
As a ROA maps against existing directories, you either will have to implement an extensive directory tree with index.phps at each level (preferably using a template like PHPTAL) for the views. But this is only good for STATIC objects. In other words for the "fixed" aspect that shape the system.
For example these resources can be fixed:
/customer
/supplier
/organization
But these resources must be dynamic:
/customer/1001
/supplier/new
/organization/staff/accounting/
Why? Because supporting or instantiating a directory structure for each entity is ridiculous. It is often method used for primitive resources: e.g. images contained in a resource mapped (i.e. customer_id in path) resource path. Often reflected by placing these images in files on disk.
Images will probably always just act like one dimensional arrays of bytes, accessed by a path name. The object handling is implicitly tied to system calls.
But if I want to dynamically create an object that has new functions being added to it - then its behaviour is not merely dump a file in a predictable way. The HTTP PUT carries a different set of semantics along with it, and this is handled in code.
So how do you access a resource on
/organizatation/staff/accounting/101
without it being a directory structure on the disk?
htaccess
URL Rewriting is an art that allows you to translate a dynamic predictable path like
/organization/staff/accounting/101
to
/organization/staff/accounting/customer.php?id=101
or
/orgaanization/staff.php?dept=accounting&customer_id=101
htaccess URL rewriting allows you to do this.
The rest of the ROA implementation using PUT to create a resource, GET to view it, POST to update it, DELETE to remove it - can be accomplished fairly easily.
Thursday, January 29, 2009
Tuesday, January 13, 2009
NZ ISPs to be pirate police
NZ Herald discussion page
A new law in New Zealand makes ISPs responsible for cutting off copyright pirates. This is all a bit silly.
For a start, define "pirate". A pirate is not the same thing as a thief. A pirate is someone who steals contraband. What is contraband? Goods in transit that have not yet been destination cleared. So, how is a "downloader" a "pirate"?
When a downloader also allows uploads. Then the downloader is effectively trafficking in contraband.
The law should cover that activity, and that activity only when it can be proven to have been done deliberately for stolen profits. That people confine their internet and cultural needs to channels that exist is not their fault. They are naturally curious.
What about the ISPs that provide access to dodgy sites? That is something so easily controlled that all a copyright claimant has to do is to ask for the offending source of copyright violation is nationally filtered. Won't happen, the government will not want to be seen encouraging censorship.
But when you make the consumer a target of the law, you are making innocents into targets for the law. It is not only socially repressive, but it is damaging.
Allow the kid who has no other access to TV to watch it without insisting his parents inspect what he is doing 24/7. Easily done. How?
Filter the damn traffic at source (or at least at the ISP), then you have nothing to worry about. Yes it is a violation of our freedom, but if the government is going to limit my free speech and curiosity, I would rather they did not threaten the curious, but let wandering minds be free to wander elsewhere. Removing their access is reactive and ineffective.
Since TVNZ purports to offer a free TV download service that hardly works through my Orcon connection, it is going to be very hard to prosecute those who download TV. The law should realize that TVNZ is offering a useless service. That is a primary cause for breaches of copyright.
My stance on this is simple. I am against piracy of copyright material. I am against threats to the general public. I see no balance in the new law and predict it will fail.
Never kill the messenger, or the consumer. As the Government can direct an ISP to filter an IP address it deems is a copyright violation - it is just a line in a computer file. So the law is an ass. A total stupidity, and waste.
A new law in New Zealand makes ISPs responsible for cutting off copyright pirates. This is all a bit silly.
For a start, define "pirate". A pirate is not the same thing as a thief. A pirate is someone who steals contraband. What is contraband? Goods in transit that have not yet been destination cleared. So, how is a "downloader" a "pirate"?
When a downloader also allows uploads. Then the downloader is effectively trafficking in contraband.
The law should cover that activity, and that activity only when it can be proven to have been done deliberately for stolen profits. That people confine their internet and cultural needs to channels that exist is not their fault. They are naturally curious.
What about the ISPs that provide access to dodgy sites? That is something so easily controlled that all a copyright claimant has to do is to ask for the offending source of copyright violation is nationally filtered. Won't happen, the government will not want to be seen encouraging censorship.
But when you make the consumer a target of the law, you are making innocents into targets for the law. It is not only socially repressive, but it is damaging.
Allow the kid who has no other access to TV to watch it without insisting his parents inspect what he is doing 24/7. Easily done. How?
Filter the damn traffic at source (or at least at the ISP), then you have nothing to worry about. Yes it is a violation of our freedom, but if the government is going to limit my free speech and curiosity, I would rather they did not threaten the curious, but let wandering minds be free to wander elsewhere. Removing their access is reactive and ineffective.
Since TVNZ purports to offer a free TV download service that hardly works through my Orcon connection, it is going to be very hard to prosecute those who download TV. The law should realize that TVNZ is offering a useless service. That is a primary cause for breaches of copyright.
My stance on this is simple. I am against piracy of copyright material. I am against threats to the general public. I see no balance in the new law and predict it will fail.
Never kill the messenger, or the consumer. As the Government can direct an ISP to filter an IP address it deems is a copyright violation - it is just a line in a computer file. So the law is an ass. A total stupidity, and waste.
Sunday, January 4, 2009
A model of a business
RESTful Business models seem to proceed presently as follows:
/business/address/street/street_number
/business/contact/email
/business/staff/executive/manager
and so forth. Nouns are nice as they relate to tangibles, that in turn have attributes, actions resulting in changes in their state.
This subject-noun centralisation appears to make sense but is that Resource Orientated? Probably not, unless you see a business as a container of raw materials. It enforces hierachy in development. This is our business module. This is our contacts module. And so forth. Objects are then "business", "user", "customer", "inventory", "cash", etc.
Seems right. Which means it is probably best deconstructed.
An earlier approach was to use gerunds to name actions:
/contact[ing]/customers
/sell[ing]/products
but then software to "contact" has to interface with diffent data types, each one differently. It makes more sense to define a business as a thing that can contact, and to define other things that can contact similiarly. The OO concept of extensibility addresses this linguistically:
where the path:
/entity/contact/email
may define
/business/contact/email
and
/staff/contact/email
by making entity a parent class to business and staff. But why include the path in the URI? If we consider each element as a semantic pair:
entity/business contact/email
then we are constructing our URI to include implied parent classes.
Our objects define:
entity as a parent of business
entity contact method when its a business
business contact method is inherently the entity contact method
the uri may say:
/business/contact/email
or
/entity/contact (which type of contact may be defined by the entity type)
therefore:
subject nouns require a superclass (categorisation) to define generic methods.
Generic actions imply a switch/case decision tree.
/business/address/street/street_number
/business/contact/email
/business/staff/executive/manager
and so forth. Nouns are nice as they relate to tangibles, that in turn have attributes, actions resulting in changes in their state.
This subject-noun centralisation appears to make sense but is that Resource Orientated? Probably not, unless you see a business as a container of raw materials. It enforces hierachy in development. This is our business module. This is our contacts module. And so forth. Objects are then "business", "user", "customer", "inventory", "cash", etc.
Seems right. Which means it is probably best deconstructed.
An earlier approach was to use gerunds to name actions:
/contact[ing]/customers
/sell[ing]/products
but then software to "contact" has to interface with diffent data types, each one differently. It makes more sense to define a business as a thing that can contact, and to define other things that can contact similiarly. The OO concept of extensibility addresses this linguistically:
where the path:
/entity/contact/email
may define
/business/contact/email
and
/staff/contact/email
by making entity a parent class to business and staff. But why include the path in the URI? If we consider each element as a semantic pair:
entity/business contact/email
then we are constructing our URI to include implied parent classes.
Our objects define:
entity as a parent of business
entity contact method when its a business
business contact method is inherently the entity contact method
the uri may say:
/business/contact/email
or
/entity/contact (which type of contact may be defined by the entity type)
therefore:
subject nouns require a superclass (categorisation) to define generic methods.
Generic actions imply a switch/case decision tree.
Subscribe to:
Posts (Atom)