|
im snyping here!
|
#
?
Sep 17, 2013 01:18
|
|
|
|
| # ? Jun 11, 2024 10:07 |
|
|
Nomnom Cookie posted:im not a fan of content negotiation. it breaks the expectation that you can look at a URL and know what it contains Those are both valid arguments. The question is whether the expectation is reasonable or not, I guess. Do you mind that imgur image links all return the same data type even though you put in a .png, .jpg, or .gif? SHould you mind? In what case is it acceptable or not? I'm having a hard time figuring out if a reasonable expectation or not depends on whatever the user thinks should happen, with or without regard to your documentation. I can hardly see the unnecessary support burden outside of "everyone puts the version in the URL, so just do it too so nobody gets confused", which has, objectively, some value as an argument. MononcQc fucked around with this message at 01:23 on Sep 17, 2013 |
|
#
?
Sep 17, 2013 01:21
|
|
|
right its not necessary to confuse your api consumers. you can put the version in the url and it will work. any alternative that introduces additional complexity has to overcome that with a corresponding benefit, and i don't see a worthwhile benefit to making http headers part of your api spec
|
|
#
?
Sep 17, 2013 01:27
|
|
|
cookies are kind of a red herring because cookies are a user agent thing. an http api that uses cookies is the devil's work
|
|
#
?
Sep 17, 2013 01:30
|
|
|
Things currently used in HTTP headers that may affect API consumers and may generally be supported or not without nobody going batshit: charset, encoding, language, date formats, authorization (basic/md5), cache stuff and TTLs, connection behaviour, attached metadata (cookies), content-type of messages accepted or sent (including compression), number of forwards allowed, proxy auth details, references to alternative resources, session data, etc. poo poo that is definitely too confusing for YOSPOS: versions. These only work in URLs.
|
|
#
?
Sep 17, 2013 01:50
|
|
|
MononcQc posted:Things currently used in HTTP headers that may affect API consumers and may generally be supported or not without nobody going batshit: accept-encoding: gzip. this is my actual opinion
|
|
#
?
Sep 17, 2013 01:52
|
|
|
MononcQc posted:poo poo that is definitely too confusing for YOSPOS: versions. These only work in URLs. yospos isn't your average api consumer they are dumber
|
|
#
?
Sep 17, 2013 01:52
|
|
|
im a big fan of dumb codeMotherfucking Brian Kernighan posted:Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
|
|
#
?
Sep 17, 2013 01:55
|
|
|
connection behavior is fine to specify in headers cause it doesnt affect the application. the server handles those version headers require an application to handle the whole point i was trying to get across is theres no upside to version as a header and loads of downside in that you have to manage a 3rd component that routes based on those headers. if you use versioned urls then you don't have that downside. that's the difference. everything else is the same. also http session state doesn't exist, application state does. how you implement it is up to you. cookies is how browsers do it
|
|
#
?
Sep 17, 2013 01:55
|
|
|
cookies have an rfc
|
|
#
?
Sep 17, 2013 01:57
|
|
|
the bsd boys posted:im snyping here! can you go snype over there instead?? thanks!
|
|
#
?
Sep 17, 2013 01:58
|
|
|
Nomnom Cookie posted:cookies have an rfc yes, but they aren't part of http. they are implemented on top of it. urls, on the other hand, are a core component. locating an http service using a url is the way its supposed to be done. locating a service via http header is doable, but not as reliable or as common.
|
|
#
?
Sep 17, 2013 01:59
|
|
|
you can abuse the poo poo out of http, but i'd rather you didn't.
|
|
#
?
Sep 17, 2013 02:01
|
|
|
that's an awfully fine distinction to make. afaik its the only ietf-standardized http state management mechanism and pretty much everyone uses either cookies or a variation on PHPSESSID
|
|
#
?
Sep 17, 2013 02:01
|
|
|
MononcQc posted: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. my point being that http is poorly suited to this use case. shoulda used a socket someone at your firm clearly figured that out and made a fuckin tcp endpoint. so what is the http adapter for?
|
|
#
?
Sep 17, 2013 02:04
|
|
|
Shaggar posted:connection behavior is fine to specify in headers cause it doesnt affect the application. the server handles those version headers require an application to handle downside of versions-as-headers: you have to look at headers to do poo poo upside of versions-as-headers: you can do much better negotiation of content versions with or without the consent of the other endpoints, dealing both with dumb and smart users, but may require more effort. Explained by RFCs and poo poo. upside of versions-as-urls: it is dumb and simple downside of versions-as-urls: unflexible and ad-hoc
|
|
#
?
Sep 17, 2013 02:06
|
|
|
basically i don't gotta build a straw man in this thread about abuse of http mononcqc made a real argument that it's a good thing to build peer to peer systems out of a client-server protocol that in no way accounts for his weird uses
|
|
#
?
Sep 17, 2013 02:06
|
|
|
MononcQc posted:downside of versions-as-headers: you have to look at headers to do poo poo everything in http other than sending content to a browser is unflexible and ad-hoc, http is not an rpc mechanism
|
|
#
?
Sep 17, 2013 02:06
|
|
|
MononcQc posted:downside of versions-as-headers: you have to look at headers to do poo poo content negotiation using versions in headers is unflexible and ad-hoc. if you don't understand my content type you cant proceed. my content type can be anything i want and you need to understand it outside of http. its literally no different than versioned urls. Shaggar fucked around with this message at 02:12 on Sep 17, 2013 |
|
#
?
Sep 17, 2013 02:09
|
|
|
and when it comes to real common content-types like json and xml you can negotiate which one to use within a versioned url system cause its just about picking the right serialization engine. the message + service versions are the same regardless of serialization type. the actual format of the json and xml is defined externally by the version. if you do application/custom.json.v_1 then you're just as inflexible as a versioned url but now you have that custom version processor on the server which adds nothing but added overhead.
|
|
#
?
Sep 17, 2013 02:11
|
|
|
Notorious b.s.d. posted:my point being that http is poorly suited to this use case. shoulda used a socket TCP came first. But TCP has downsides for syslog log messages because the RFC for TCP-Syslog doesn't allow for things like retransmission with deduplication, which means timing out on a request may or may not lead to duplicated data. HTTP allows people to get poo poo done with a plug-and-play web server, adding custom headers to identify duplicate data if it needed to be retransmitted, and optionally encrypt log data over SSL/TLS with HTTPS without any additional development effort on either side. This could be all done over raw TCP, but would probably trickier for consumers for these log messages given they (and we) would need to implement whatever mechanism, including security features, from scratch, or using a much less known protocol that many proxies may block just for the hell of it.
|
|
#
?
Sep 17, 2013 02:12
|
|
|
use protocol buffers. just be careful not to do something incompatible
|
|
#
?
Sep 17, 2013 02:14
|
|
|
Shaggar posted:content negotiation using versions in headers is unflexible and ad-hoc. if you don't understand my content type you cant proceed. my content type can be anything i want and you need to understand it outside of http. its literally no different than versioned urls. Shaggar posted:if you do application/custom.json.v_1 then you're just as inflexible as a versioned url but now you have that custom version processor on the server which adds nothing but added overhead.
|
|
#
?
Sep 17, 2013 02:16
|
|
|
i'm really, really glad i don't work with mononcqc his company sounds like a shitshow however cool and fp-focused his job is
|
|
#
?
Sep 17, 2013 02:20
|
|
|
Notorious b.s.d. posted:i'm really, really glad i don't work with mononcqc Let me know how you'd implement it. This can be a good/fun exercise.
|
|
#
?
Sep 17, 2013 02:22
|
|
|
log to files and logstash to aggregate. it's p easy to do DIY splunk with that + kibana
|
|
#
?
Sep 17, 2013 02:24
|
|
|
MononcQc posted:Using HTTP mechanisms you can try more than one over many calls and discover what works or not. It is all ad-hoc (past what is defined in RPCs), but is in no way worse than using versioned URL -- it in fact decouples versions from location. you aren't decoupling anything., you're hard coupling a new message processor in front of your service. that's reduced flexibility. and if your client is trying multiple things to "figure out what works" it means the client is broken and doesnt understand the service. the client cant figure out what works from http alone. it requires you to program what works into the client, either thru github incorrect wiki (the terrible idiot way) or thru a service definition document (the right way). ex: the service has one definition of the fields for a person object. it can accept it as xml or json. if the client sends application/bonderfart.custom[420]XXXxxx.totalbespoke_v_2 then it means the client was written by someone who doesnt have any idea what the service does. if the client sends json AND the json is missing fields and therefore invalid, trying to switch to xml isn't gonna help cause the field is gonna be missing in the xml as well. the serializer isn't gonna magically add a missing field nor is the server going to tell it what field is missing (in a way the client can use to fix the problem).
|
|
#
?
Sep 17, 2013 02:26
|
|
|
conditions and restarts never caught on outside of lisp for good reason. its not a good model to bring to http
|
|
#
?
Sep 17, 2013 02:28
|
|
|
Shaggar posted:you aren't decoupling anything., you're hard coupling a new message processor in front of your service. that's reduced flexibility. let's say you're a dumb yosposter and your first version doesn't support utf-8 because you're an English-speaking ethnocentrist. You only do ASCII or latin-1 and drop characters. You decide to update your data format to something that supports that, and also timezones in the timestamps, compared to the previous format. You make this public as v2 of your API. You document it. In one case you make it in the URL, the other the headers. In the URL, it's an either/or case. You either updated or not based on the URL. In the other case, when it's unknown, you can send the newest one or the oldest one depending on your backwards compatibility policy. If the user specifies it in the header, you use that one. There is no difference in any of what you said depending on whether it's done in the URL or not. One just gives a bit more control than the other, to the service provider.
|
|
#
?
Sep 17, 2013 02:36
|
|
|
Nomnom Cookie posted:log to files and logstash to aggregate. it's p easy to do DIY splunk with that + kibana no you see logstash supports an HTTP api it is garbage. ALso splunk does it also.
|
|
#
?
Sep 17, 2013 02:39
|
|
|
MononcQc posted:no you see logstash supports an HTTP api it is garbage. ALso splunk does it also. nah logstash works fine. idc how it works it moves logs from nodes to the log server edit: programming is building a statue, out of garbage, on top of garbage. so i dont really mind if something is garbage
|
|
#
?
Sep 17, 2013 03:03
|
|
|
MononcQc posted:let's say you're a dumb yosposter and your first version doesn't support utf-8 because you're an English-speaking ethnocentrist. You only do ASCII or latin-1 and drop characters. You decide to update your data format to something that supports that, and also timezones in the timestamps, compared to the previous format. You make this public as v2 of your API. versioned url benefits to the service provider: flexibility in determining where the service lives (separate from others, same as others, routed by proxy, etc...) versioned url downsides tot he service provider: versioned header benefits to the service provider: versioned header downsides to the service provider: locked into where the service lives (either one service that handles all versions or a single router that sends them to the right place based on header). client impact urls are easier for the client to use since most http clients are designed to handle common headers and urls. to support custom version headers would require additional client work. Not a big deal, but annoying. once that's done though there really is no difference to the client when versions change in either system. they can continue using the old or update to the new just as easily either way. the service provider is therefore the only one the choice impacts and i hope they would choose to use versioned urls as it is more reliable because it is less complex.
|
|
#
?
Sep 17, 2013 03:03
|
|
|
Notorious b.s.d. posted:i'm really, really glad i don't work with mononcqc fwiw I am dead serious in that I would like to get your (and anybody else's) opinions on implementation ideas for protocols. I personally designed none of these and got the fun maintenance task. It would be sweet to get ideas for the next thing given it should: - maintain long-lived connections (reconnecting is always slow) - allow for multiple sessions/connections between any two endpoints (i.e. a service provider should be able to receive data on behalf of many different users from the same node) - allow processing timeouts (infinite timeouts are a bad thing) - support control flow mechanisms (we can drop messages, but must be able to know about it to report the losses) - allowing for retries/retransmissions is a good plus, but not vital (we turn ambiguous case in reported losses) - batching is useful given the nature of logs (throughput > low latency) - optionally encrypt data for safe transmission over unsecured networks - be supported by as many platforms and languages as possible (who gives a poo poo about a thing nobody can use) - be conceptually simple enough, for the same reasons as above - the protocol should be extensible, but at this point this is just a plus - can unambiguously represent string data -- encoding can be agreed upon if standard, though - compression is a plus, but not necessary - be CPU-efficient so that a single user doesn't make CPUs spin 100% - be memory-efficient for the same reason - be bandwidth-efficient, for the same reason - etc. Things like MQTT looked particularly interesting, but is gonna be harder to get adoption for, and has nothing for crypto being baked in.
|
|
#
?
Sep 17, 2013 03:12
|
|
|
im not joking abt logstash. the hierarchy is make ops deal with it > someone elses code > your own code logstash makes it an ops problem...u flush the log file and then done. now its not ur problem anymore
|
|
#
?
Sep 17, 2013 03:16
|
|
|
Shaggar posted:versioned url benefits to the service provider: Every place I've worked at went that way, and as I said before, I can totally see why. I'm still believing it would be nice to do it without the URL and just using the headers, to be entirely pure on the HTTP side of things. Fwiw, Proxies like HA Proxy are able to route based on HTTP Headers, and would probably give you the same flexibility as routing from the URL path (but less than using things like subdomains). In some way, making the header optional gives you the same thing as making the version optional in the URL, which I've seen done quite a few times.
|
|
#
?
Sep 17, 2013 03:19
|
|
|
purity is a  goal unless it impacts reliability, usability, performance, etc...metrics
|
|
#
?
Sep 17, 2013 03:21
|
|
|
MononcQc posted:- optionally encrypt data for safe transmission over unsecured networks if you don't want pretend encryption, I don't think you can do all of these without riding on something else
|
|
#
?
Sep 17, 2013 03:23
|
|
|
MononcQc posted:Every place I've worked at went that way, and as I said before, I can totally see why. I'm still believing it would be nice to do it without the URL and just using the headers, to be entirely pure on the HTTP side of things. haproxy can also route based on a combination of headers, url path, sni, and tls npn. yes i've seen this done. i was an accessory
|
|
#
?
Sep 17, 2013 03:23
|
|
|
Nomnom Cookie posted:purity is a which is why I have never forced any of the products I work on to use whatever scheme I had with that and went with the easiest poo poo possible. Which is how you also end up using HTTP to route poo poo where better protocols ought to be used 
|
|
#
?
Sep 17, 2013 03:24
|
|
|
|
| # ? Jun 11, 2024 10:07 |
|
|
Brain Candy posted:if you don't want pretend encryption, I don't think you can do all of these without riding on something else Yeah, which I have been told is a clown thing to do in this here thread.
|
|
#
?
Sep 17, 2013 03:25
|
|