Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78836
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D6194C8A-3375-4BA7-87C6-358A8247966E@ajf.me>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
	<CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com>
	<CAL+t6cHDLHjTE3JK0md=KZ=AnRns6iYxfphzA3qnShermVeOmg@mail.gmail.com>
	<1DDB6E05-3143-4A74-8B13-AF85222579BA@ajf.me>
	<CAL+t6cH92NgWnr-0gh9AfTxX_1r5Fd0=+M6SeZu53BT3nPHSEg@mail.gmail.com>
	<468730E8-4C38-49A3-A61A-59E107313D79@ajf.me>
	<CAL+t6cGPiqZXx2rQCzSV-PCzAAJtMWi6xteCU0GB0XjsB4wSpA@mail.gmail.com>
	<545C1823.8050404@sugarcrm.com>
	<D6194C8A-3375-4BA7-87C6-358A8247966E@ajf.me>
Date: Fri, 7 Nov 2014 00:16:34 -0500
Message-ID: <CAL+t6cHSze7ojSu8SsF0gb11-x-fozYGxYbW95TJ+uSAv-KShw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Patrick ALLAERT <patrickallaert@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04138ae39edcea05073dea0e
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: theanomaly.is@gmail.com (Sherif Ramadan)

--f46d04138ae39edcea05073dea0e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> > On 7 Nov 2014, at 00:53, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> >
> > Hi!
> >
> >> Again, I think you're oversimplifying the problem. For one, you don't
> know
> >> that the payload is JSON unless you check the Content-type header
> yourself,
> >> and you really shouldn't have to since PHP could easily do this for yo=
u.
> >
> > Sure, PHP could easily do this, or any other one specific use case for
> > you. What it can't do, however, is to do all 1000 use cases that modern
> > REST application presents, automatically for you. What if you use XML
> > and not JSON? What if you use both and determine which one it is by
> > request URL suffix being .xml or .json? What if it instead is switched
> > by query parameter? What if also it can be compressed, encrypted and
> > wrapped in some MIME multipart message? Having all these complications
> > handled in the core of PHP would be extremely hard, not because each of
> > them is hard, but because there can be so many of them. And you'd run a
> > big change of PHP still not matching your specific case exactly, or
> > being behind times, because core can not evolve as quickly as userland
> > does. That's why it's better done in extensions or user space - unless
> > you can identify a case which covers a huge proportion of all cases -
> > just like forms are for POST. For generic REST, I'm not sure there's
> > such case, except for very generic API giving access to the basic
> > request, its fields and supporting basic URL/MIME parsing.
>
> Even just parsing JSON isn=E2=80=99t as simple as it sounds. There are se=
veral
> things users might like to configure, several ways to parse JSON (objects
> vs. arrays, big numbers as floats or strings, etc.), while for form-data
> there=E2=80=99s only one way.
>

Well, in this case it will be parsed as an array since $_POST is naturally
parsed as an array. Also, since $_POST/$_GET are typically always processed
as strings it would only make sense to use big numbers as strings in the
JSON parsing as well. I don't think this is the big issue. The bigger issue
is do users typically find the population of $_POST more useful than just
reading the input stream themselves and handling the JSON payload on their
own.


>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--f46d04138ae39edcea05073dea0e--