Unifying REST API searches with the interface method getList() and http ...

[SchumacherFM]

...method PUT.

Deleted POST routes and merged them to a PUT route to be more consistent with all other getList implementations.

[SchumacherFM]

The two tests which are failing are not mine and some date tests:

1) Magento\Framework\Data\Form\Element\DateTest::testGetValue with data set #0 (array('short', 'short', 1420187502), '01/2/15 12:31 AM')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'01/2/15 12:31 AM'
+'1/2/15 12:31 AM'

[choukalos]

Link to internal issue ( MAGETWO-31679 ); Looks like builds are failing as API tests have been added into most recent builds - failing since POSTS have been changed to PUTS.

Internally on this issue there's some debate between using PUT vs GET for search operations. Do you-all prefer PUT given the complex search parameters that can be passed?

[Vinai]

Just on a side note, the test fail is not related to the POST -> PUT change but because of the issue fixed in PR #913.

[birchestx]

There is a limit in Internet Explorer as I understand with GET requests - 2048 chars. I'm not sure on how that applies to PUTs but know at WSA we use POST in some instances rather than GET for this and other reasons.

[avoelkl]

According to HTTP standards, GET is used to request a resource which - in my opinion - a search is.
PUT is used for storing new resources (or update them), POST to add sub-resources.
So the correct method would be GET.

[alankent]

Agreed - PUT is for creating new resources, not doing a search. GET is most correct semantically if you just have a URL, POST is necessary when the URL is not / cannot be used to pass in parameters. PUT is not appropriate if there are no side effects (e.g. no new database entity has been created, as in a search).

[SchumacherFM]

In that case (Alan) there needs to be more API routes changed from PUT to POST.
The search query can easily grow to more than 2048 chars so that GET could/would fail.

{
    "search_criteria": {
        "filter_groups": [
            {
                "filters": [
                    {
                        "field": "attribute_name",
                        "value": [string|int|float],
                        "condition_type": [string]; optional
                    }
                    more entries
                ]
            }
            more entries
        ],
        "current_page": [int] page number; optional
        "page_size": [int] number of items on a page; optional
        "sort_orders": [ optional
            {
                "field": "attribute_name",
                "direction": [int] -1 or 1
            }
            more entries
        ]
    }
}

[alankent]

Yep (SchumacherFM). They should definitely be all made consistent.

[TexanHogman]

Based upon some research looks like IE9+ overcome 2048 limit. We have an internal ticket opened to convert all REST search requests to GET. Most importantly is getting them consistent.

[avoelkl]

+1 for making them consistent.

Would be great if we could make it to implement GET. That would be one of a few really correct implemented REST APIs.

[GordonLesti]

REST in my eyes:

• POST - create resource
• GET - returns resource
• PUT - edit resource
• DELETE - delete resource

A search isn't really part of REST in my eyes, but GET matches the most for me. Maybe POST, but not PUT.

[choukalos]

@SchumacherFM can you update the PR to 'GET' & address the travis build failure?

Based on the feedback & discussion with our lead architect, @TexanHogman, this is the route we'd like to go because we call out IE9+ for full support right now in M1 ( 1.9 / EE 1.14 for responsive theme [link}http://www.magentocommerce.com/knowledge-base/entry/ee114-ce19-rwd-dev-guide#support] ).

Thanks

[SchumacherFM]

I will do. I'm closing this PR and send you a new one.

Thank you everybody for contributing!

[alankent]

Just to comment on PUT = update and POST = create, here is a more accurate way to say it: http://restcookbook.com/HTTP%20Methods/put-vs-post/
That is, PUT is good if you know the url. When you create a new entity in Magento, Magento allocates the unique ID so PUT is not appropriate and POST better.