
Ask HN: Current best practices when POST as GET seems unavoidable? - michaelsbradley
When the concern of &quot;very long URLs&quot; rears its head (and just won&#x27;t go away) in REST API design discussions for read-only endpoints, <i>and</i> when there&#x27;s enough time for careful planning of a new or overhauled API, what are the best practices in 2017 for using POST as if it were GET?<p>The following answer on Stack Overflow seems to have merit, but what strategies are really working well for you real world API implementers?<p>https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;30767665&#x2F;how-to-be-restful-with-long-urls&#x2F;30773811#30773811<p>It would be nice if &quot;use GraphQL instead&quot; was an option, but let&#x27;s assume it must be a plain old REST-ish HTTP API.
======
fulafel
You can always refer to long data by URI. Either a locator where the data is
available, or other kind of identifier that names a previously created
resource.

You can make it more human-readable than a "wall of parameters" too, if you
succeed in naming the parameter data that way.

~~~
michaelsbradley
Yes, that's more or less the solution given in the SO answer to which I
referred. I like your idea of giving the created resources human-friendly
names/paths; it may be that the POST data can even indicate a preferred name,
though the server may need to modify the name to preserve uniqueness, etc.

------
CyberFonic
The SO answer by user1907906 would be my preference as well.

It appears that you trying to wrap generic SQL queries with REST. That is not
really the intended use case for REST. A GET should be retrieving a single
resource or small set of resources with relatively few query parameters.

Since REST is not suitable for "query heavy" use, I would prefer to use
GraphQL if that is the nature of your API. If you are prevented from using
GraphQL, then the SO solution is probably your next best bet.

~~~
michaelsbradley
You're spot on. This pertains to a more or less homegrown query DSL (or family
of DSLs) that gets "translated," in a sense, by the server to SQL and/or
MongoDB queries. The read-only endpoints being queried represent collections
of a great many items, so being able to filter–search for, say, a dozen to a
few thousand at a time is a real need.

Using GraphQL would probably be better, but if it's not an option then it's
not an option.

I am, though, looking at dynamic-rest[1] and Eve's "projections"[2] for
inspiration, i.e. to allow for flexible queries that more closely match
particular use cases (of the API's users).

[1] [https://github.com/AltSchool/dynamic-
rest](https://github.com/AltSchool/dynamic-rest)

[2] [http://python-eve.org/features.html#projections](http://python-
eve.org/features.html#projections)

------
mengledowl
I'm curious why GraphQL isn't an option - if you're already submitting the
request as a POST, what's preventing you from using GraphQL?

~~~
michaelsbradley
Assume management isn't willing to make it part of the stack at this time, and
that's the end of the discussion.

