Take the 2-minute tour ×
Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

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
}

share|improve this question
    
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... –  Kevin Montrose May 30 '10 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 May 30 '10 at 9:26
    
@S.Mark - nvarchar(MAX) I suppose. –  Kevin Montrose May 30 '10 at 9:49
3  
@kevin it should probably match the current engine code which is 30000 char body and 150 char title –  Jeff Atwood May 30 '10 at 22:18
add comment

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
1  
Thank you very much Kevin, suggested_buffer_size would be ok. –  YOU Jun 1 '10 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? –  Brock Adams Jun 11 '13 at 18:56
    
@BrockAdams confirmed, those buffer limits are not in version 2.0+; caused way too many headaches for not enough gain. –  Kevin Montrose Jun 17 '13 at 17:47
    
Understandable. Thanks, @KevinMontrose. –  Brock Adams Jun 17 '13 at 20:27
add comment

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
},
...

share|improve this answer
add comment

You must log in to answer this question.

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