2

For the type "string", I think there is some upper limit of character count.

For example,

  • post title : 200 characters
  • post body : 30000 characters

In the help page, currently like this

"body": {
    "description": "body of the comment",
    "values": "string",
    "optional": false
}

Can we have upper limit also? for example

"body": {
    "description": "body of the comment",
    "values": "string",
    "max-length": 30000,
    "optional": false
}

4
  • Strictly speaking, these are limitations on the currently deploy'd SO codebase independent of the API. There's no min/max length enforced anywhere in that chain. Not to say we couldn't expose the SO limits... but I'm forced to ask, why would you need this data? I certainly hope you're not allocating MAX_STRING_LEN anywhere... Commented May 30, 2010 at 8:05
  • @Kevin, There is VARCHAR size in table field settings in my MySQL database, so I am just wondering how to set those.
    – YOU
    Commented May 30, 2010 at 9:26
  • @S.Mark - nvarchar(MAX) I suppose. Commented May 30, 2010 at 9:49
  • 3
    @kevin it should probably match the current engine code which is 30000 char body and 150 char title Commented May 30, 2010 at 22:18

2 Answers 2

3

Alright, here's what we're going to try.

First off, we're not giving hard guarantees as to the maximum length of strings returned. Such a guarantee could create a situation where we might have to release an API revision just to accommodate increased text limits on the trilogy sites, or one - which is equally bad - where the API would return truncated results until the next "natural" revision.

Furthermore, spelling out exact character limits brings us into the realm of Unicode dragons; which, frankly, is asking alot of developers. This complexity can be seen full force in Twitter's API. People do like to use lots of Unicode, so it'd be a more common problem than you might think.

What we are doing is putting our current limits as suggested_buffer_size in the documentation. These are, at best, hints. Any code you write must be able to handle larger data if its returned. This code will get pushed into production later tonight, in all likelihood.

Update: The suggested_buffer_size limits/properties were removed from the version 2.0+ API. They caused way too many headaches for not enough gain.

3
  • 1
    Thank you very much Kevin, suggested_buffer_size would be ok.
    – YOU
    Commented Jun 1, 2010 at 2:50
  • Please confirm that suggested_buffer_size did not make it into the current version of the API. If it did make it, how do we invoke these help pages? Commented Jun 11, 2013 at 18:56
  • @BrockAdams confirmed, those buffer limits are not in version 2.0+; caused way too many headaches for not enough gain. Commented Jun 17, 2013 at 17:47
0

Well done! now returned JSON on help pages are like this

...
"title": {
    "description": "title of this post",
    "values": "string",
    "optional": false,
    "suggested_buffer_size": 200
},
"body": {
    "description": "body of this post.",
    "values": "string",
    "optional": true,
    "suggested_buffer_size": 30000
},
...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .