|
tbh I like the version-in-the-url solution cause any clients using the new version can update url at the same time and it provides the ability to cleanly separate your entire service stack version wise. if you put version in the message (either as a header or in the content), your server needs to understand every version or atleast how to redirect each version to a server that can process it. so if you want to keep lots of backwards compatibility around you end up with a pile of redirected stuff in there which means any downtime or configuration changes on the redirector for any reason affect all versions. if you don't keep many versions around its probably not a big deal, but the url solution is less problematic.
|
#
?
Sep 15, 2013 23:44
|
|
|
|
| # ? May 27, 2024 13:13 |
|
|
Shaggar posted:tbh I like the version-in-the-url solution cause any clients using the new version can update url at the same time and it provides the ability to cleanly separate your entire service stack version wise. if you put version in the message (either as a header or in the content), your server needs to understand every version or atleast how to redirect each version to a server that can process it. so if you want to keep lots of backwards compatibility around you end up with a pile of redirected stuff in there which means any downtime or configuration changes on the redirector for any reason affect all versions. if you don't keep many versions around its probably not a big deal, but the url solution is less problematic. i like the version-in-url because it makes poo poo obvious to the poor loving schmuck troubleshooting a bad configuration REST and SOAP assholes both make a big deal out of human readability in a tcpdump or what have you. stuffing poo poo in the request instead of the headers is a good example of being obvious to humans
|
|
#
?
Sep 16, 2013 00:55
|
|
|
just have /v1/whatever and /v2/whatever etc... then when you watch to switch over its an easy find and replace in your .js files to update
|
|
#
?
Sep 16, 2013 00:57
|
|
|
soap is the best, but failing that wcf rest is acceptable. wcf has message logging for debugging which is real nice. whats even nicer is when people just generate a client + classes from the wsdl instead of trying to do the xml themselves.
|
|
#
?
Sep 16, 2013 00:59
|
|
|
coffeetable posted:the standard definition uses uniform distributions, but that's just because it makes a lot of proofs simpler. it's not integral to the concept A non-uniform distribution doesn't pass the next-bit test, i.e. you can predict the next bit in a sequence of random numbers with probability strictly greater than 50%. https://en.wikipedia.org/wiki/Next-bit_test Soricidus posted:yagni, unless you're like literally a terrorist or a spy. java.util.Random is faster and ideal for all your high-performance legal cryptographic needs.  From http://docs.oracle.com/javase/6/docs/api/java/util/Random.html: The class uses [...] a linear congruential formula. ... http://security.stackexchange.com/questions/4268/cracking-a-linear-congruential-generator
|
|
#
?
Sep 16, 2013 01:32
|
|
|
double riveting posted:
whats jokes precious
|
|
#
?
Sep 16, 2013 05:45
|
|
|
BP posted:whats jokes precious sorry, sarcasm detection might have been off...
|
|
#
?
Sep 16, 2013 09:51
|
|
|
Shaggar posted:tbh I like the version-in-the-url solution cause any clients using the new version can update url at the same time and it provides the ability to cleanly separate your entire service stack version wise. if you put version in the message (either as a header or in the content), your server needs to understand every version or atleast how to redirect each version to a server that can process it. so if you want to keep lots of backwards compatibility around you end up with a pile of redirected stuff in there which means any downtime or configuration changes on the redirector for any reason affect all versions. if you don't keep many versions around its probably not a big deal, but the url solution is less problematic. what if you went with a combination, where you have a new url when you have a new major version, but minor versions use the existing url and have to maintain backward compatibility?
|
|
#
?
Sep 16, 2013 12:48
|
|
|
if a minor version doesn't change message compatibility then its fine. if it does then its actually a major version and needs a new url. minor versions don't need their own urls
|
|
#
?
Sep 16, 2013 15:33
|
|
|
Shaggar posted:tbh I like the version-in-the-url solution cause any clients using the new version can update url at the same time and it provides the ability to cleanly separate your entire service stack version wise. if you put version in the message (either as a header or in the content), your server needs to understand every version or atleast how to redirect each version to a server that can process it. so if you want to keep lots of backwards compatibility around you end up with a pile of redirected stuff in there which means any downtime or configuration changes on the redirector for any reason affect all versions. if you don't keep many versions around its probably not a big deal, but the url solution is less problematic. You seem to assume a scheme where the request-response pattern always happens from client to service provider. Turn it around and make it a push-based system, where you forward events to your clients. You cannot assume that the URL structure respects anything you know. The registration to the service may have happened 6 months ago, and they have no incentive to upgrade or re-register all the hooks they've put in the system. Using content-types as your negotiation mechanism, the client has a way to specify or understand which version of whatever document markup or type is being used, react accordingly, and let the caller do graceful degradation based on whatever is supported. Then use keep-alive requests and you need to do that detection once per session only. The 'version-in-URL' scheme may work reasonably well when you're the one being called all the time. If what you do in any way depends on you calling your clients, then it breaks. The header type negotiation thing works in all cases no matter what.
|
|
#
?
Sep 16, 2013 23:16
|
|
|
Otto Skorzeny posted:gently caress the single-space-after-sentence police: http://www.heracliteanriver.com/?p=324 ahahahahaha quote:While the modern convention is the single space, it is no less arbitrary than any other, and if you believe that larger spaces after periods look better in some situation, you should feel confident that your choice is supported by hundreds of years of good typographical practice. For the record, before we go further, my preference is not for double-spacing, but for a slightly larger sentence space, about 1.5 times an interword space for most typefaces. But unlike the modern single-space fanatics, I don’t judge anyone’s aesthetic preferences, nor will I try to make up fairy tales using fabricated history to convince you... modern typefaces adjust kerning so that spaces after periods are wider; perhaps, just perhaps, about 1.5 times the width of a 'normal' space. this guy wrote thousands of words to painstakingly document the historical background of his point, and he's still an idiot, arguing with other idiots who are (coincidentally) right. there's still no reason to add multiple spaces after a period unless you're typing on a selectric or an apple iic.
|
|
#
?
Sep 16, 2013 23:27
|
|
|
I still want a text editor that renders blank lines at half their usual height
|
|
#
?
Sep 16, 2013 23:35
|
|
|
MononcQc posted:You seem to assume a scheme where the request-response pattern always happens from client to service provider. the client would get a message version based on the version in the url on which they sent their notification/registration request
|
|
#
?
Sep 16, 2013 23:42
|
|
|
qntm posted:I still want a text editor that renders blank lines at half their usual height use HTML with <p> for paragraphs representing empty lines and use that to do whatever you want 
|
|
#
?
Sep 16, 2013 23:43
|
|
|
Shaggar posted:the client would get a message version based on the version in the url on which they sent their notification/registration request that assumes you either control the URL scheme the endpoint uses or that you're feeling okay guessing whatever they are doing and how it compares to your stuff, though. This kind of defeats the point of letting the user add whatever URL they want as a callback endpoint.
|
|
#
?
Sep 16, 2013 23:45
|
|
|
PleasingFungus posted:modern typefaces adjust kerning so that spaces after periods are wider; perhaps, just perhaps, about 1.5 times the width of a 'normal' space. the article posted:Oh, and by the way, you’ll hear some advocates for single-spacing talking about how modern fonts can take into account the extra spacing needed to the period in the font itself. But this is also an elaborate lie. Such kerning after periods would require sensitivity to abbreviations versus ends of sentences, something no font can do by itself. (Some publishing software and word processors do try.) Besides, I’ve seen no evidence that most professional fonts actually incorporate kerning pairs involving periods and spaces—in fact, it would be ridiculous to do such a thing, because it would interfere with the spacing adjustments that typographers still do. (I’ve read elsewhere where someone examined over 2000 standard Adobe Opentype fonts and found that only about 20% of fonts kerned period-space combinations, and only about 1% kerned question mark or exclamation points followed by spaces. In all cases where there is kerning, it is negative, i.e., it actually reduces the space after the period, rather than increases it.)
|
|
#
?
Sep 16, 2013 23:45
|
|
|
MononcQc posted:that assumes you either control the URL scheme the endpoint uses or that you're feeling okay guessing whatever they are doing and how it compares to your stuff, though. of course you control the url scheme for your server
|
|
#
?
Sep 16, 2013 23:45
|
|
|
ex: client posts w/e their endpoint url is to http://whatever.boners/bonerservice/v1/registerforboneralerts whether its 5 minutes or 5 years from now when they get a boneralert its gonna be in the v1 format. their endpoint url is irrelevent
|
|
#
?
Sep 16, 2013 23:48
|
|
|
Unless you have some plans to develop a "please update this endpoint" API call of some sort, this kind of thing supports no way to do things like upgrading the data format, and also does nothing in order to allow figuring out the desired format, if you can compress data, the version of the data you're using, or whatever. Or if you do, you'll reinvent mechanisms equivalent to what is supported by basic HTTP already and that you're using in some way already.
|
|
#
?
Sep 16, 2013 23:50
|
|
|
two responses to that: (1) I actually read up a little more on it after making my first post, and apparently the actual change isn't increasing the width of the space after periods; it's moving the period to the left, so it fits 'snugly' with the preceding letter & creates an effectively wider space to the right. (2) lol if u read a thing
|
|
#
?
Sep 16, 2013 23:52
|
|
|
changing data formats is never automatic and will always require a human to update the endpoint. the notification that they need to update their endpoint is when it goes out of service cause they haven't responded to your irl notifications. sure you could notify their client that the format is dead, but theres no guarantee they'll handle it. as for figuring out which formats they support, they support the format you provide.
|
|
#
?
Sep 16, 2013 23:52
|
|
|
Shaggar posted:changing data formats is never automatic and will always require a human to update the endpoint. the notification that they need to update their endpoint is when it goes out of service cause they haven't responded to your irl notifications. How about this: - develop a RESTful API, and make it known that you deal with documented mimetypes, whether they are custom or not. - you make a notification that a new format will be supported starting yyyy/mm/dd (notice the good date format) - you enable the new date format - when you post data to the endpoint, the user can answer with a given HTTP code. Make it known firsthand that you will deal with the accept-type headers or whatever. - On codes like 400s (or 500s depending of the kind of changes you made), check the value returned and use it if you still support it. If none is on there, you may or may not just try to fall back to another one. This is like the endpoint telling you the kind of XML schema you provide it can deal with. - Keep the working format active for the entire session - If the client can't agree with the server, fail the way you would on a service sending JSON to an XML-accepting client. - You can piggy-back on that mechanism to deal with compression and other poo poo This basically just having the regular protocol be able to handle a version negotiation automatically without you having to guess numbers in the /vN/ URLs.
|
|
#
?
Sep 17, 2013 00:01
|
|
|
right, you just have to guess at the version headers, mime types, data formats, and error codes.
|
|
#
?
Sep 17, 2013 00:03
|
|
|
Shaggar posted:right, you just have to guess at the version headers, mime types, data formats, and error codes. as opposed to ad-hoc URL paths and querystrings, random arguments, or custom data formats you created in your own little snowflake of an app to do the same drat poo poo in a roundabout way that nobody else uses.
|
|
#
?
Sep 17, 2013 00:05
|
|
|
all messages are ad-hoc in relation to http. theres no such thing as standard http content. its the standards (established[soap] or custom[rest]) on top of http that make it useful. you can write your own bespoke attempted auto-detecting router that picks out custom headers to determine what the message content is so it can be routed to the appropriate service or you can write your own bespoke version url that sends it to the appropriate service. the former requires an additional point of failure that's missing from the later and also doesnt add any benefit except maybe the client doesnt need to update the service url (which is not an actual problem cause they're gonna have to update everything else when a new version comes out). so again p-langers develop added complexity to avoid extra typing.
|
|
#
?
Sep 17, 2013 00:10
|
|
|
Shaggar posted:all messages are ad-hoc in relation to http. theres no such thing as standard http content. its the standards (established[soap] or custom[rest]) on top of http that make it useful. shaggar was right
|
|
#
?
Sep 17, 2013 00:14
|
|
|
MononcQc posted:You seem to assume a scheme where the request-response pattern always happens from client to service provider. http is always client-server by nature, so yes, i do in fact assume "a scheme where the request-response pattern always happens from client to service provider". that is how http works if you pervert the standard and do weird poo poo out of band, that's your own problem. has nothing to do with the soundness of stuffing the api version into the url
|
|
#
?
Sep 17, 2013 00:14
|
|
|
Notorious b.s.d. posted:http is always client-server by nature, so yes, i do in fact assume "a scheme where the request-response pattern always happens from client to service provider". that is how http works "weird poo poo out of band" = a server making an http request to another server? what is so weird and out of band about using the headers and error codes for exactly what they were defined for again?
|
|
#
?
Sep 17, 2013 00:26
|
|
|
its weird to use headers for resource location instead of using uniform resource locators.
|
|
#
?
Sep 17, 2013 00:35
|
|
|
Shaggar posted:all messages are ad-hoc in relation to http. theres no such thing as standard http content. its the standards (established[soap] or custom[rest]) on top of http that make it useful. You are already doing all of that detection. You're doing it on content-type for JSON, XML, whatever SOAP requires. You're doing it for content encoding (UTF/ISO whatever). You're doing it for compression. You're possibly doing it for authentication, locales, user agents, connection management, and all other kinds of poo poo. Then your idiot API decides that instead of extending all of that pre-existing logic at work on every call to do version negotiation, you'll instead add a bunch of ad-hoc knobs to be turned in whoever knows what way because developers are idiots who can't document poo poo properly. Because it's easier to grep for an URL than doing something that makes sense. Notorious b.s.d. posted:http is always client-server by nature, so yes, i do in fact assume "a scheme where the request-response pattern always happens from client to service provider". that is how http works lol if you've never had server-to-server communications of some sort. It can be based on HTTP and the requester-receiver change on each call.
|
|
#
?
Sep 17, 2013 00:40
|
|
|
Shaggar posted:its weird to use headers for resource location instead of using uniform resource locators. location =/= representation in all cases.
|
|
#
?
Sep 17, 2013 00:40
|
|
|
MononcQc posted:You are already doing all of that detection. You're doing it on content-type for JSON, XML, whatever SOAP requires. You're doing it for content encoding (UTF/ISO whatever). You're doing it for compression. You're possibly doing it for authentication, locales, user agents, connection management, and all other kinds of poo poo. quote:Then your idiot API decides that instead of extending all of that pre-existing logic at work on every call to do version negotiation, you'll instead add a bunch of ad-hoc knobs to be turned in whoever knows what way quote:lol if you've never had server-to-server communications of some sort. It can be based on HTTP and the requester-receiver change on each call. MononcQc posted:location =/= representation in all cases. all messages from service v1 will have the same representation. knowing the location of service v1 means i know the representation im looking for.
|
|
#
?
Sep 17, 2013 00:53
|
|
|
MononcQc posted:You are already doing all of that detection. You're doing it on content-type for JSON, XML, whatever SOAP requires. You're doing it for content encoding (UTF/ISO whatever). You're doing it for compression. You're possibly doing it for authentication, locales, user agents, connection management, and all other kinds of poo poo. http is client-server by nature if you're using it for communication between peers, you're doing your own wild out of band thing. have fun with all your pointless corner cases next time use a socket, chump
|
|
#
?
Sep 17, 2013 00:54
|
|
|
also server to server is still client to server
|
|
#
?
Sep 17, 2013 01:01
|
|
|
Shaggar posted:all messages are ad-hoc in relation to http. theres no such thing as standard http content. its the standards (established[soap] or custom[rest]) on top of http that make it useful. actually its p easy for haproxy to route based on headers the #1 argument against a custom header imo is that people will gently caress it up. tell them "GET this URL" and they can probably figure it out 80% of the time. tell them "send the X-Version header with one of these values" and they WILL gently caress it up
|
|
#
?
Sep 17, 2013 01:02
|
|
|
the reason it will confuse them is because custom headers are not the norm for resource location.
|
|
#
?
Sep 17, 2013 01:03
|
|
|
MononcQc posted:You are already doing all of that detection. You're doing it on content-type for JSON, XML, whatever SOAP requires. You're doing it for content encoding (UTF/ISO whatever). You're doing it for compression. You're possibly doing it for authentication, locales, user agents, connection management, and all other kinds of poo poo. im not a fan of content negotiation. it breaks the expectation that you can look at a URL and know what it contains Shaggar posted:the reason it will confuse them is because custom headers are not the norm for resource location. i agree and if i'm building a service i'd rather make something that works and move on rather than build in an unnecessary support burden
|
|
#
?
Sep 17, 2013 01:06
|
|
|
you could call it the uniform resource locator locator or "urll". i bet you could get the w3c to sign off on it given how terrible html5 was
|
|
#
?
Sep 17, 2013 01:14
|
|
|
Shaggar posted:that's all well and good but its not what we're talking about. We're talking about the version of the message (schema + serialization formats) we're sending (aka the version of the service). yes. And what if that is represented as a mimetype? say 'application/shaggars-api-v1-xml' for the serialization format and schema for the data? How is this worse than a v1 or v2 in a URL for ad-hoc bullshit? Shaggar posted:idk what you mean. the service has to be defined outside of http. there is nothing in http that defines message formats so it must be done either programmatically (wsdl) or bespoke (github wiki). If I get a mimetype for a JPG image, that is the actual message. If I get a PDF and specify the format, that is also a thing. I could make an endpoint that represents a resource as HTML, JSON, XML, Atom, or whatever, and the client would decide what to ask for. Define a new mimetype and use it there, and bam, you both get to define your poo poo and re-use HTTP's mechanisms instead of using them and reinventing part of them out-of-band (or tunneling it through HTTP) to represent the format. I don't particularly care which way you do it -- a github wiki, a well-known standard, or using some mapping of mimetypes to wsdls or whatever -- URLs for versionning is dumb and this is what this discussion is about. Shaggar posted:yes and they'll use a previously agreed upon message(service) version which has specific urls. At this point this is behaviour you need to specify in some way in any API no matter what language or protocol you use. That HTTP is good or not for your specific use case is debatable, but in no way HTTP being a bad choice for your case makes URL versionning suddenly better. Shaggar posted:all messages from service v1 will have the same representation. knowing the location of service v1 means i know the representation im looking for. Now take that pretty v1 of yours and put it somewhere else than the URL. And it still works. Why aren't you debating pushing HTTP sessions as part of the URL too? Because they are done in headers (cookies) and that seems fine, even though a given representation is tied to your access rights. The version, the session, whatever, are all contextual information that doesn't necessarily need to be tied to the resource location. MononcQc fucked around with this message at 01:18 on Sep 17, 2013 |
|
#
?
Sep 17, 2013 01:16
|
|
|
|
| # ? May 27, 2024 13:13 |
|
|
Notorious b.s.d. posted:http is client-server by nature Here's a use case from work, real world poo poo. We have a log router. Your app outputs poo poo, it makes it to the router. You yourself contact the router and ask for logs. You can also ask the router to push logs to either a TCP Syslog endpoint, an HTTP endpoint, or an HTTPS endpoint by giving it an URL. In this case: - the app is the log router's client, but can also just be a dumb input stream over TCP. - you are the log router's client, but on a different endpoint and API - the log router is your log endpoint's client on every page of data it sends to it. i.e. the log router can behave both as a client and a server depending who it talks to. Sockets are used where necessary. HTTP can be used when requested. Your point being?
|
|
#
?
Sep 17, 2013 01:17
|
|