Pages: 1 [2] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.25 21:49:00 -
[31]
Originally by: Hel O'Ween
Originally by: Tonto Auri Pediwikia isn't the best place to read about technical specifications. It only good at providing non-technical information for non-technical (i.e. informative) purposes.
I don't care to read further about technical details if Twitter has its hands in the design.
*grin*
Quote:
Quote:
Totally forgot (and wtf noone mentioned?) HTTP response codes to indicate API response status. It's "a bit" off to have HTTP 200 OK containing actual error message.
That depends from which angle you're looking at it. 200 OK makes sense, because the *web* server was technically able to web serve your request. That the database backend might not be able to answer your request should be of no concern for the web server.
Following your logic, anything except 5xx errors should be "Ok", as "web server was able"... It's not depends on web server, what is the actual result of request. Application decide. (And I mean both client and (actual backend) server application)
Quote: I can see pros and cons for both positions as long as the behavior is consistent.
If you're using certain protocol for your needs, you'd be stupid to invent your own overheads reimplemention it's already present functionality. I hope CCP learned from their StacklessIO exersises... (However, that's a thin hope...) -- Thanks CCP for cu |
darius mclever
|
Posted - 2010.10.25 22:02:00 -
[32]
Originally by: Hel O'Ween
Originally by: Tonto Auri Pediwikia isn't the best place to read about technical specifications. It only good at providing non-technical information for non-technical (i.e. informative) purposes.
I don't care to read further about technical details if Twitter has its hands in the design.
oauth is an open standard. twitter just happens to use it.
Quote:
Quote:
Totally forgot (and wtf noone mentioned?) HTTP response codes to indicate API response status. It's "a bit" off to have HTTP 200 OK containing actual error message.
That depends from which angle you're looking at it. 200 OK makes sense, because the *web* server was technically able to web serve your request. That the database backend might not be able to answer your request should be of no concern for the web server.
I can see pros and cons for both positions as long as the behavior is consistent.
actually ... HTTP is just a medium. you are speaking to the application over the protocol, so if e.g. the old cached information is still correct it could give me a 304 return code instead of http 200 and some weird error in the xml.
or if my account ran out, it could answer every request with 402 payment required. ;) (my favorite return code.)
that said ... encoding the error into the body and having the client to guess from it doesnt make sense for every state that is handled in the http protocol.
|
Hel O'Ween
Men On A Mission
|
Posted - 2010.10.26 08:32:00 -
[33]
Originally by: darius mclever
oauth is an open standard. twitter just happens to use it.
Twitter *drafted* the standard (and uses it, of course). *Big* difference for me. But my personal dislike of social web services is out of scope of this discussion.
Quote:
actually ... HTTP is just a medium. you are speaking to the application over the protocol, so if e.g. the old cached information is still correct it could give me a 304 return code instead of http 200 and some weird error in the xml.
or if my account ran out, it could answer every request with 402 payment required. ;) (my favorite return code.)
that said ... encoding the error into the body and having the client to guess from it doesnt make sense for every state that is handled in the http protocol.
The problem is, you need more/other error codes than the HTTP protocol does provide. Of course, you could use 304 for the caching. But what about "Invalid beforeRefID provided"?
You also seem to forget that HTTP error codes were defined when the web consisted of static pages. There was no "application to talk to". The web server could either retrieve the requested page from the file system or not. Which explains its lack of error codes that support modern web development (i.e. the biggest junk of sites meanwhile is generated on the fly).
As I said, consistency is the key her for me. Adding HTTP error codes to the game and keeping the API error codes doesn't make sense to me. You need to implement the parsing of the API error codes anyway. -- EVEWalletAware - an offline wallet manager |
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.26 09:38:00 -
[34]
Edited by: Tonto Auri on 26/10/2010 09:46:38
Originally by: Hel O'Ween The problem is, you need more/other error codes than the HTTP protocol does provide.
:'( I though I wouldn't need to explan such simple things to you. HTTP does not "provide error codes". It defines meaningful error code ranges, which application could utilize. Of course, there's some actual error codes defined (such as 401 Unauthorized or 403 Forbidden), but a whole range of them are up to application to define meaning.
Quote: Of course, you could use 304 for the caching. But what about "Invalid beforeRefID provided"?
You put one of the 4xx codes for it to use. You could simply use vague 400 code depicting general client error, however, but that would be poor solution.
Quote: You also seem to forget that HTTP error codes were defined when the web consisted of static pages.
As I said, you lack understanding of protocol definitions.
Quote: There was no "application to talk to".
There were and are. The fact that web servers was the protocol and application all-in-one does not render meaningless the fact that HTTP standard was designed to be extensible as imaginary possible.
Quote: As I said, consistency is the key her for me. Adding HTTP error codes to the game and keeping the API error codes doesn't make sense to me. You need to implement the parsing of the API error codes anyway.
You are making a fundamental mistake... One that many beginner programmers make, however, and one not easy to relearn. Suggested reading: http://tools.ietf.org/html/rfc2068#section-10 Especially, the Quote: 10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
-- Thanks CCP for cu |
Catari Taga
Centre Of Attention Middle of Nowhere
|
Posted - 2010.10.26 10:08:00 -
[35]
While Tonto in his usual charming way is correct about the nature of the HTTP protocol, if the move towards the use of HTTP status codes was made (and I consider it unlikely since this isn't something PrismX can tweak on his own) it would have to go along with proper Last-Modified: and Expires: headers and support HEAD requests. --
|
Hel O'Ween
Men On A Mission
|
Posted - 2010.10.26 14:57:00 -
[36]
Thanks for the lesson, Tonto. I'm serious, no sarcasm here.
Originally by: Tonto Auri
:'( I though I wouldn't need to explan such simple things to you. HTTP does not "provide error codes". It defines meaningful error code ranges, which application could utilize.
Simplicity lies in the eye of the beholder.
I'm an old grunt (aka "desktop developer"). This newfangled web stuff still scares me ...
Quote: 10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
Extensible ... I get it. -- EVEWalletAware - an offline wallet manager |
Catari Taga
Centre Of Attention Middle of Nowhere
|
Posted - 2010.10.26 16:58:00 -
[37]
Originally by: Hel O'Ween
Quote: 10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.
Extensible ... I get it.
If you go quote the spec, this would be the better section:
Originally by: HTTP/1.1 6.1.1 Status Code and Reason Phrase
[...]
HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached.
;) --
|
darius mclever
|
Posted - 2010.10.26 19:36:00 -
[38]
Originally by: Hel O'Ween
Originally by: darius mclever
oauth is an open standard. twitter just happens to use it.
Twitter *drafted* the standard (and uses it, of course). *Big* difference for me. But my personal dislike of social web services is out of scope of this discussion.
Yes one employee of Twitter was in the initial group that discussed the oauth standard. but what about the 2 other guys?
anyway, i forgot one important thing: with oauth you could use (api|www).eveonline.com to authenticate users on 3rd party sites. (e.g. like twitter and others allow), that would save 3rd party sites implementing their own authentication scheme, especially when the sites later use informations from the API anyway.
|
Ix Forres
Caldari Righteous Chaps
|
Posted - 2010.10.26 21:01:00 -
[39]
OAuth/OAuth2 is a simple, sensible and extensible protocol for authenticating desktop and web/mobile applications with ease while keeping things secure. Coupled with a scope parameter of some form, complete granular control of what apps had access to would be trivial - app requests features X, Y and Z, user is told and accepts or refuses the request when authenticating the app to their account. It's an open standard with no lock-in, loads of library support in any language you care to use, and easy on CCP's part to implement it. And it ties in nicely with OpenSocial, the open widget standard, if CCP ever went down that route with EVE Gate.
HTTP error codes, headers, etc, should be the primary method of communicating request/response states. That's fairly obvious in terms of best practices, and should be done already. There's no harm in including _additional_ information as part of the response body. But error codes on the request itself should go with the HTTP specification as closely as possible. In most cases, those error codes are logical mappings - wrong/expired key = 401/3, invalid ID for things like wallet/characterName etc = 400, and so on. Headers for cache expiration dates and so on should likewise be set. Apart from anything else this makes HTTP caching heaps easier for CCP - throw a cache server like Varnish/Squid in front and write some code to invalidate all caches that include a certain API key in their key when someone changes their API key/account status changes. Heck, that'd probably make a decent amount of improvement to performance for very little effort.
All this sort of thing in my mind is very obvious, simple and any decent web application programmer or system architect can tell you that they're no-brainers as far as application behavior goes. Why CCP has not previously done this is beyond me, and of course we'll never know.
But I digress I run on somewhat. I'm assuming Mazzilliu has ignored this thread by and large, and passed on whatever actually got passed on to CCP, who will also promptly ignore it or cherry-pick one suggestion that involves no actual work or politics to get sorted out. -- Ix Forres - 3rd Party Application Developer - EVE Metrics - accVIEW
|
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.10.26 23:50:00 -
[40]
Originally by: Hel O'Ween Thanks for the lesson, Tonto. I'm serious, no sarcasm here.
Sorry, if that was feeling rude. I didn't mean any harm. (And I really like the extensibility and simplicity of HTTP and it's sister mail/mime format) -- Thanks CCP for cu |
|
Hel O'Ween
Men On A Mission
|
Posted - 2010.10.27 00:22:00 -
[41]
Originally by: Tonto Auri
Sorry, if that was feeling rude. I didn't mean any harm.
No need to be sorry. I didn't feel offended (or harmed, for that matter). I learned something new, which is a good thing. As I'm not working in the marketing department, I value facts much higher than style. -- EVEWalletAware - an offline wallet manager |
Wollari
Phoenix Industries Black Star Alliance
|
Posted - 2010.10.27 10:02:00 -
[42]
Originally by: Ix Forres [...] passed on whatever actually got passed on to CCP, who will also promptly ignore it or cherry-pick one suggestion that involves no actual work or politics to get sorted out.
Quote for thruth.
I actually would like to see a discussion, roundtable with CCP and the developer community, who have (without doubt) a huge impact on the overall player experience (since the majority of players are using their community products).
I bet that these "developer" have also impact on the fact that people are staying in the game (keeping subscribed == ccp gets money) since they're providing so many good tools, webpages, etc that helps player to understand the game. Without all these helpers (character tools, skillplaner, maps, market analysis tools), newcomers would likely run away cause they don't understand the game.
So CCP ...
Originally by: Wollari
- We're one of your best marketing tools.
- We help you that new players find their path in New Eden and actually stay in the game.
- We help people enjoy the game, out of the game.
- We're much more worth then any online marketing banner campaign on youtube or wherever.
So CCP get this in your money mind:
Helping the developer community means, helping all players (new and old).
Lets talk, lets work together (open or behind closed doors), commit to work on the API/with us, honour, respect, maybe reward the work of all of us and keep us happy.
@Mazzilu: Thanks for including my document/wishlist in your feedback document.
|
Sherksilver
|
Posted - 2010.12.03 21:48:00 -
[43]
Nice list: On POS / Towers: -- Definitely something to indicate tower module belongs to tower X -- Would love to have Tower Fuel values available in the API based upon the Fuel Tech role instead of Director role / access levels. <-- This would be extremely useful.
|
Tonto Auri
Vhero' Multipurpose Corp
|
Posted - 2010.12.03 21:58:00 -
[44]
-- Thanks CCP for cu |
|
|
|
Pages: 1 [2] :: one page |
First page | Previous page | Next page | Last page |