GET puts all your params on the URL like;
http://example.com/thing?foo=bar&x=y
For POST you could include all that information but it won’t show in the URL.
http://example.com/thing
Obviously if you’re thinking about security, using POST is more ideal because your params won’t show in access logs or accidentally picked up by search engines or whatever. Sending passwords using this method is ideal in additional to large amounts of data.
But what you can loose with POST is caching. Some systems will not cache a POST. Assuming you want to ditch the the cache on a GET request you can always throw on a cache buster.
http://example.com/thing?foo=bar&x=y&cache=234234234
Where &cache=<current-time-or-random-number>. And maybe that’s what you want for your more posts. To not cache them so you’re always getting the freshest of the fresh. Unfortunately if you do anything at scale this idea fails. Cache is King and controlling the cache is ideal.
Enter the TTL (Time to Live) where you can add how long you’d like your resource to be cached on the other end.
header('Expires: '.gmdate('D, d M Y H:i:s \G\M\T', time() + (60 * 60))); // 1 hour
or nocache_headers() // no caching
Now, for your case, I don’t think it matters one bit which one you use. But the questions to ask yourself should include;
- Do you want to expose your data passed to the URL?
- Should you be concerned with caching?
- How can you control caching to make it optimized for your content and system?