TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

JSON in URLs

54 点作者 leahculver大约 10 年前

18 条评论

AlexeyMK大约 10 年前
A little confused. The author is arguing _against_ JSON in URLs, right?<p>The piece starts as a list of complaints about hacky query parameter encoding, and has the feel of one of those &quot;aren&#x27;t these things annoying... but here&#x27;s the right answer!&quot; posts, except instead of a correct answer we get a discussion of how JSON is nice in some cases but we shouldn&#x27;t use it in URLs, except maybe sometimes.<p>Is this a response to some post about how JSON _should_ be used in URLs? Overall, I struggled to find a coherent narrative &#x2F; argument here. Perhaps something went wrong in the article&#x27;s editing process.
评论 #9265326 未加载
评论 #9265315 未加载
Someone1234大约 10 年前
Even this article&#x27;s final conclusion is that this is a bad idea.<p>Data within the URL also has a number of other issues including:<p>- It is easier to leak (e.g. browser history, proxies, some browser extensions, etc). Very few things record HTTP POST parameters unless they&#x27;re doing something evil, very many non-evil pieces of software record the full URL.<p>- Users intentionally or inadvertently re-posting data is much more likely. No browser&#x27;s autocomplete re-posts HTTP POST parameters to the website, many will do so with HTTP GET parameters, which could result in a worse user experience (or in rare cases the user performing actions on your website within intending to).<p>- Maximum length<p>- The encoding&#x2F;decoding step could be extremely expensive for some data. JSON itself requires a lot of decoding but depending on what you&#x27;re moving it could mean almost all of the data requires it making the URL string insanely massive.<p>- Users will copy&#x2F;paste these URLs to one another and the JSON will remain in all its 200+ character ugly glory. This may not be a security issue but it is a user perception issue. URLs are meant to be getting cleaner&#x2F;more human readable.
评论 #9266331 未加载
namesbc大约 10 年前
A JSON like syntax that is URL query compatible sounds like a great solution to me. Rison tried this approach a couple years back: <a href="https://github.com/Nanonid/rison" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Nanonid&#x2F;rison</a>
评论 #9266052 未加载
lolatu54大约 10 年前
Well that has a smell doesn&#x27;t it. There may be a use case where you feel the need to stuff a url with json data, but it sure feels wrong.
espadrine大约 10 年前
I designed something similar while writing scoutcamp (an express.js competitor). I made it so that it could parse both normal queries (eg, `?age=12&amp;cards=visa&amp;cards=mastercard`) and JSON (eg, `?age=12&amp;cards=[&quot;visa&quot;,&quot;mastercard&quot;]`).<p>I&#x27;d argue that design is easier to read and allows graceful degradation: someone using an API with fields `age` and `cards` can rely on the traditional way to work. They can easily reformulate their query when more complex structures are required. Yet Ajax scripts can use a simple shim to make XHR calls that send arbitrary JSON data.<p><a href="https://github.com/espadrine/sc/blob/master/lib/camp.js#L82" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;espadrine&#x2F;sc&#x2F;blob&#x2F;master&#x2F;lib&#x2F;camp.js#L82</a>
评论 #9266650 未加载
endymi0n大约 10 年前
related: <a href="http://evertpot.com/dropbox-post-api/" rel="nofollow">http:&#x2F;&#x2F;evertpot.com&#x2F;dropbox-post-api&#x2F;</a><p>Basically everything about the status quo is messed up.<p>JSON into parameters: bad.<p>JSON into request body: undefined with the GET method.<p>JSON into request body with POST: great, but we&#x27;re not actually mutating anything, so it&#x27;s bad practice and won&#x27;t be cached by varnish&#x2F;nginx + a barrage of other problems.<p>I really wish someone would take up on <a href="http://www.ietf.org/rfc/rfc3253" rel="nofollow">http:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc3253</a> - like REPORT as an analogue to GET, just with a JSON request body. Hey, we as a community finally managed to get PUT and PATCH on track, why not this one?
评论 #9266461 未加载
mschuster91大约 10 年前
When I pass around any parameters in GET or POST parameters I wrap them in base64. That makes a <i>lot</i> of escaping bugs go away (and adds a bit of &quot;security by obscurity&quot;, as well as true security when combining the query with a random number, a sha256 hash of the parameters and a serverside secret).
评论 #9265727 未加载
评论 #9265514 未加载
评论 #9265405 未加载
评论 #9265717 未加载
SloopJon大约 10 年前
May I recommend the following blog post:<p><a href="http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding" rel="nofollow">http:&#x2F;&#x2F;blog.lunatech.com&#x2F;2009&#x2F;02&#x2F;03&#x2F;what-every-web-developer...</a><p>and the HN discussion of that post:<p><a href="https://news.ycombinator.com/item?id=5930494" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5930494</a><p>I used JSON in the URL to preserve the state of a report across reloads. I kind of regret it, because it wouldn&#x27;t have been that much work to maintain a URL with normal query args. I think I had in mind that JSON would better handle things like the collapse&#x2F;expand state of nested groups (a tree, essentially), but mostly I was just lazy, considering that I never got that far.
asabil大约 10 年前
Once you get there, maybe base64url binary blobs are way more efficient and quite compact.
评论 #9266349 未加载
Tloewald大约 10 年前
We actually do something similar to this to make our application state (within limits) be reflected by the url and support navigation — both good things. The urls are horrible though and we&#x27;re considering simply storing the state in a service and giving it a serial number (but this has its own issues).<p>I was hoping the article was proposing a better way of encoding Json as urls, e.g. using the characters that are allowed in place of curly braces etc and doing simple translation. E.g {&quot;foo&quot;:&quot;bar&quot;,&quot;baz&quot;:[]} becomes foo=bar&amp;baz=&amp;&amp;
评论 #9266167 未加载
hashberry大约 10 年前
JSON in URL: &#x2F;log?%7B%22a%22:%22b%22,%22c%22:4%7D<p>You are debugging and need to quickly identify the values you are passing to the API. Better have a JSON parser handy.
评论 #9265305 未加载
urvader大约 10 年前
We have used this syntax for url filters, works surpricingly well:<p>&#x2F;v1&#x2F;movies?year&gt;=2011&amp;artist!=cage<p>meaning - to add more meaning to the parameters in the query string, just add a suffix to the fieldname &gt;&lt;!~ etc. Before using the query, just filter them out. To add an array of options, just add the same field twice or use comma in the value:<p>&#x2F;v1&#x2F;movies?year&gt;=2011&amp;artist!=cage&amp;name=the+rock,face+off
jamiesonbecker大约 10 年前
I&#x27;m all for (ab)using specs whenever convenient, but this is just such a bad idea.<p>You will rarely actually use query args (ie ?x=y&amp;foo=1) with a true REST API anyway. Use your resource path and avoid query args except for idempotent GET operations. If you have complex data, just put it in a request body as JSON. Don&#x27;t put that crap in a query arg. That&#x27;s not what it&#x27;s for.
omgitstom大约 10 年前
Why JSON in the url as query parameters?<p>What benefit do you give you API caller?<p>What benefits do you give browser &#x2F; caller caching for GET?<p>It really feels like they needed to get some content out for some reason, and just found some post in some internal dropbox wiki and posted it. Maybe they posted a draft by accident? I dont know...
pdknsk大约 10 年前
I noticed this on the official results page of the recent Parliamentary Elections in Greece. It uses JSON in the hash.<p><a href="http://ekloges.ypes.gr/current/v/public/index.html?lang=en" rel="nofollow">http:&#x2F;&#x2F;ekloges.ypes.gr&#x2F;current&#x2F;v&#x2F;public&#x2F;index.html?lang=en</a>
amelius大约 10 年前
A simple solution that can often work is to store the JSON in a database, assign a number to it, and use that number in the URL instead of the JSON. One could even add a cryptographical checksum (e.g., hash with secret salt) to make it a bit safer.
emmelaich大约 10 年前
Reminds me of one of my favourite @apenwarr articles.<p><pre><code> &quot;Programming inside the url string&quot; http:&#x2F;&#x2F;apenwarr.ca&#x2F;log&#x2F;?m=201212#18</code></pre>
placeybordeaux大约 10 年前
So the only example of query paramaters screwing up security is actually not about url query paramaters at all.<p>What a bad article.