Ask HN: Current best practices when POST as GET seems unavoidable? | Hacker News Reader

Ask HN: Current best practices when POST as GET seems unavoidable?

When the concern of "very long URLs" rears its head (and just won't go away) in REST API design discussions for read-only endpoints, and when there'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?

The following answer on Stack Overflow seems to have merit, but what strategies are really working well for you real world API implementers?

https://stackoverflow.com/questions/30767665/how-to-be-restful-with-long-urls/30773811#30773811

It would be nice if "use GraphQL instead" was an option, but let's assume it must be a plain old REST-ish HTTP API.

View on HN

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.

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.

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.

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

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

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?

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

Reply on news.ycombinator.com