[HN Gopher] EDI vs. API
___________________________________________________________________
EDI vs. API
Author : donzog
Score : 84 points
Date : 2022-09-12 16:21 UTC (6 hours ago)
(HTM) web link (support.edifabric.com)
(TXT) w3m dump (support.edifabric.com)
| nightski wrote:
| I'd say the fact that an API is JSON is a huge technical
| impediment to EDI. While JSON is great, it's incredibly verbose
| and not a great format for large amounts of data. Also let's face
| it, while one can design with effort an API that is capable of
| all the requirements of EDI, the vast majority of APIs out there
| are not implemented in this fashion. I just am having a hard time
| agreeing with this article at all.
| peheje wrote:
| You can put anything in body, doesn't have to be json format.
| Could be csv. Base64 or binary etc.
| calvinmorrison wrote:
| There's no requirement for API's to only accept JSON. I mean we
| had SOAP (bleck)
| cestith wrote:
| JSON, YAML, XML, and several other formats are basically
| various failed attempts to reimplement the utility and
| simplicity of s-expressions.
| nightski wrote:
| I agree, but in the article they define an API as one
| accepting JSON. So I was just going with the conventions they
| were using.
| soco wrote:
| If they built a strawman argument we don't have to accept
| it.
| nightski wrote:
| Agreed that is what I was trying to say in my comment
| haha. I didn't like the article.
| robertlagrant wrote:
| But then it's not a huge technical impediment to EDI. It's
| just what some article said.
| Existenceblinks wrote:
| If we are talking about HTTP here:
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
| hk1337 wrote:
| They really shouldn't be pitted against each other. They have
| some similarities but typically EDI is intended for bulk data
| transfers where a Web API is more suited for smaller amounts of
| data, like one record per request/response. Sure, an API can do
| lists but compared to an EDI, the file can handle a lot more
| records.
|
| *EDIT* Typically, EDI is good for a once daily update where an
| API can handle the incremental changes that occur throughout the
| day.
| themadturk wrote:
| Tell that to the EDI customers I work with, who either dribble
| out (or receive) data almost constantly, or dump thousands of
| files on us at once.
| hk1337 wrote:
| We probably do that but EDI is the only automated solution
| available aside from scraping their web site. Depending on
| the time of the month the request can be small or several
| account numbers at once.
|
| We try and keep track of when the last time we made a request
| for a particular account number and only request it once a
| month but there's days where there is a lot of account
| numbers and there are days where there are none.
|
| The amount of the request may be small but the files coming
| back would be usage data and 15 minute interval data.
| peheje wrote:
| api can receive files, what am i missing
| hk1337 wrote:
| The bulk data part. EDI would likely be more useful when you
| want updates on 100,000+ records at once, each record with
| multiple fields.
| kortex wrote:
| An api can still do that. I do this all the time with
| json/http apis: a bulk_upsert endpoint and you just
| feed/stream a batch of objects. Never did a bulk_patch but
| the implementation is nearly the same.
|
| If I cat all those patch objects to a file on a shared
| drive, knowing that at midnight UTC every day, it'll get
| picked up and applied, that's _still_ an API, albeit a
| kinda janky transport layer.
| [deleted]
| [deleted]
| raydiatian wrote:
| Go with Stedi.com instead.
|
| Longtime EdiFabric user. Never was a fan.
| dahfizz wrote:
| Since this is an article about pedantry, I am sick of people
| conflating "API" with REST or HTTP. Applications had Programmable
| Interfaces before HTTP even existed.
|
| Services hosted over the internet that let you make requests are
| a special case of "API" as far as I am concerned. System
| libraries and third party libraries are the most widely used kind
| of API, and it's not even close.
| extragood wrote:
| "What is an API?" is one of my favorite interview questions.
|
| Your answer gets full points. Partial credit for knowing what
| the initialism stands for, and having some valid explanation in
| the context of HTTP.
|
| As another example, one of my internships involved development
| of software patches so that the company's software could
| interact with various electron microscopes via their
| proprietary APIs.
| fshr wrote:
| Can you steelman allowing terminology to evolve and allowing
| new forms to be the assumed/default meaning? Also, context
| matters a lot. It's rarely ambiguous if we're talking about
| networking or libraries. When they overlap in conversation
| you'd need to clarify anyway.
| hk1337 wrote:
| > I am sick of people conflating "API" with REST or HTTP
|
| That bugs me too. lol. I have included in interviews as more of
| a fun question and conversation on what is an API.
| PaulDavisThe1st wrote:
| > I am sick of people conflating "API" with REST or HTTP.
| Applications had Programmable Interfaces before HTTP even
| existed.
|
| I am sick of people conflating "Programming" with
| "Programmable". The interface isn't programmable, it exists to
| program applications.
|
| So there.
| henning wrote:
| I work at a supply chain company that deals with both APIs and
| EDI and the product people view EDI as a crappier version of an
| API, which is one of those statements that is so meaningless that
| it's not even wrong.
| slively wrote:
| In healthcare I think the EDI would be considered HL7 if I am
| reading this correctly. I worked with HL7 for a number of years
| and it is absolutely horrendous. It does work just well enough
| and is just fast enough though. So much of the issues of creating
| larger scale health exchanges in the USA I attribute to
| monopolies in the industry (Cerner/Epic) and things like HL7.
| kazinator wrote:
| If you export your contacts in one e-mail program and import it
| into another, the import and export functions are kinds of APIs,
| but the exported format isn't.
|
| The interchange format becomes an API if you encode requests in
| it. Along that axis, it can become a programming language that
| defines a new API.
|
| If the interchange data does nothing beyond storing a
| representation of itself, which is then operated upon by some
| procedures not specified in that data itself, then it's not an
| API.
| IncRnd wrote:
| EDI is not API. Likewise, compression is not encryption, even
| though the output of a compression routine sometimes appears
| encrypted. A noun is not a verb, despite them both being parts of
| speech.
|
| EDI is an acronym for Electronic Data Interchange that uses a
| standardized format. In that way businesses don't need to send
| paper around. An EDIs standardized format is implementated with
| methods that are accessed through an API.
| JaggedJax wrote:
| All EDI is an API (of a very specific and defined type).
|
| All API are not EDI.
|
| Therefore API !== EDI
|
| All couches are furniture, but couches are not "equivalent" to
| furniture.
| floathub wrote:
| All of Alma Cogan is dead, but only some of the class of dead
| people are Alma Cogan.
| JaggedJax wrote:
| Correct. And Alma Cogan is dead, but being Alma Cogan is not
| equivalent to being dead. They have other properties that
| differ. This article claims the two are equivalent.
| moistly wrote:
| EDI is an awesome spec, and I mean that in the "Mt. Everest is
| awesome" sense: it is an _incredibly_ detailed tome covering
| every conceivable business data exchange; with an encoding
| protocol that is very efficient /succinct.
|
| If you have access to the spec, EDI is easy and kind of fun, if
| you're into parsing and manipulating data.
|
| It is in no way an API. It's a spec that tells you in painful
| detail how to write out your B2B
| quotes/orders/corrections/receipts/etc.
| femto113 wrote:
| Ironically, despite the elaborate spec most participants will
| wind up just using an ad hoc convention of embedding critical
| information in non-semantic text fields (or "note segments")
| with bespoke codes & delimiters.
| [deleted]
| Alupis wrote:
| EDI is a standardized data format with some blessed transport
| protocols that ensure disparate systems can communicate without
| needing custom integrations.
|
| I've never heard someone try to make the case that it's an API
| per-say. More like a data format, such as JSON, with prescribed
| elements, etc. What the other end-system does with that data is
| up to them... and not all data is intended for pure automated
| programatic consumption (ie. invoices, etc).
|
| The main issue with EDI is your industry either has embraced EDI
| or it hasn't... making it really difficult to use EDI if only a
| small subset of your manufacturers/vendors also support EDI.
| Typically organizations these days will support a REST API
| instead of EDI, which obviously requires quite a lot of custom
| integration work (even if using generation tools like
| swagger/openapi).
| couchand wrote:
| I've never seen an EDI implementation that required nothing
| custom. The claim is oft-repeated but based on little
| substance.
| P5fRxh5kUvp2th wrote:
| that's still not API though.
|
| EDI = data, API = functionality. They can work in tandem, but
| don't have to.
|
| you might as well say FTP is an API. In the most technical
| sense, sure.
| themerone wrote:
| Our EDI code probably has multiple if blocks for every
| customer we communicate with.
|
| Implementing EDI is not for the faint of heart. For the
| variations I worked with, there was little useful
| documentation, I learned mostly be reading existing code. I
| would hate to have to start from scratch.
| lksh_dev wrote:
| SystemOut wrote:
| This is so true. Am in logistics so can't speak to other
| verticals but every-single-implementation has something
| unique to it. Either they're on a version we haven't tested
| on, or they only support some date/time formats, or they have
| custom codes, whatever.
| andrew_ wrote:
| Worked in Logistics and can confirm. AT&T had a dozen
| different data formats for the same data across their
| network of warehouses.
| themadturk wrote:
| Also in logistics, and agree. There is danger in over-
| promising with customizations. If you're not careful to you
| can spend more time and money meeting what the customer
| wants than the actual business the customer brings in.
| WesleyJohnson wrote:
| There are companies that can help with EDI integrations so
| that both ends can use their "flavor" of EDI and they do the
| translation. SPS Commerce is one such company I know of. Not
| affiliated, but we do use them at my employer. I don't work
| on that team, though, can't offer any thing in terms of ease
| of use, pricing, etc.
| sleepymoose wrote:
| Agreed, everyone needs something just a _little_ different.
| And at least from my experience, the platforms and systems
| that build the integration are essentially disparate and held
| together with I.T. brand duct tape.
| Octoth0rpe wrote:
| I've heard EDI used both ways: referring to the very general
| concept of two systems exchanging data in which case an API is
| a way to implement EDI, and as a file format analogous to json
| often using ascii control characters (file separator, group
| separator, record separator, etc)
| soco wrote:
| And then comes OData...
| duxup wrote:
| Work in transportation. We refer to them as EDI and API and
| often phrase it "We can do EDI or API.". So we don't think of
| them as the same thing. Goals are the same most of the time,
| but I never really think of EDI as AN API.
|
| But the whole debate is a little pedantic for me. Just need to
| get it working ...
| therein wrote:
| This whole thing is like if Google insisted gRPC wasn't an
| API framework, it was just gRPC and indoctrinated every
| engineer that went through its ranks over the decades to
| perpetuate the same in other companies they join.
|
| A calling convention is an API, an ABI is an API, and I am
| even okay with going as far as saying "walking into a
| convenience store, talking to a clerk in a human language to
| retrieve items in exchange of paper currency" is an API.
| dahfizz wrote:
| > and I am even okay with going as far as saying "walking
| into a convenience store, talking to a clerk in a human
| language to retrieve items in exchange of paper currency"
| is an API.
|
| I think that is a bit far. Social customs define some sort
| of interface we use to complete transactions, but it is not
| programmable nor dealing with applications.
| masa331 wrote:
| Except that from my own experience connecting to EDI needs more
| custom programming than connecting to RESt APIs. The format is
| horrible and also the whole workflow based around sending and
| receiving messages
| jrochkind1 wrote:
| A standardized data format with some standardized transport
| protocols... how is that _not_ an API?
|
| I don't think whether the integrations need customization or
| not is relevant. Certainly many API's are "bespoke" and need
| custom integrations. But if it's designed to be standardized
| (whether it succeeds or fails, and many standards end up not
| being so standard), that certainly doesn't somehow disqualify
| it from being an API either.
|
| It might be a difficult or easy API to work with; or how
| difficult or easy it is may depend on your context and
| platform.
| rs999gti wrote:
| > Typically organizations these days will support a REST API
| instead of EDI
|
| Not in most logistics, purchase orders, and invoicing business
| cases. We have offered APIs, but most orgs want to do EDI.
|
| We have significant volume still going through EDI that we have
| to keep it running, no matter how badly we want to stop
| maintaining it.
|
| Even worse, even though there is X12 standard some orgs still
| want customizations.
|
| EDI and ACH files need to be deprecated but money talks.
| artistminute wrote:
| Isn't it crazy that X12 standards come out and are constantly
| updated to provide a way to send all the data you need in a
| standardized format however ALMOST EVERY receiver or sender
| likes to have their own flavor of it, making it near useless.
| I would rather just call it what it is and just make seperate
| systems to intake every new customers format instead of
| rewrite the existing one to work with the currently
| implemented flavor
| chrisweekly wrote:
| +1 helpful comment
|
| (tangent) Also, in the spirit of aiding understanding (and
| maybe helping non-native English speakers / writers), it's per
| se ("in itself", from Latin) not per-say (which is not a word
| -- though it'd be pronounced the same).
| nico wrote:
| Sounds a lot like SOAP/WSDLs, which ended up being mostly
| replaced by REST.
| jen20 wrote:
| The WSDL part has somewhat been replaced by OpenAPI.
| foobarian wrote:
| [GraphQL has entered the room]
| Existenceblinks wrote:
| [No one else is here]
| devnull255 wrote:
| When I worked at Electronic Data Systems (EDS) in the 90s, I
| was doing development on applications that both produced and
| ingested EDI documents based on a custom EDI standard General
| Motors imposed on both internal and external suppliers for
| Shipping Schedule (862) and Planning Schedule with Release
| Capability (830) documents. GM was able to persuade many EDI
| software companies to include the GM specs in EDI software
| releases.
|
| I don't miss working with EDI.
| [deleted]
| arpinum wrote:
| I have not heard this claim either and I work in the EDI space.
|
| No idea why this is on HN other than seeing an EDI company
| fumble a marketing article so badly while trying to stay
| relevant.
| projektfu wrote:
| Generally, EDI doesn't really contain the bits about telling
| another system what to do. You could build an API on a base of
| EDI data/document types but there will still be missing bits
| about semantics and protocol that will have to be filled in by
| your API description.
|
| If the API is "put EDI files into this directory on the FTP
| server" then, yeah, it is an API of sorts. Presumably there is an
| automated batch process that reads the files and perhaps
| generates responses.
|
| I think what people are asking for when they want API rather than
| "just EDI" is that they want something their software can use,
| that gives results and error codes they can understand, so that
| they can orchestrate and debug the process. Also, they probably
| want something they can implement without paying thousands of
| dollars to an intellectual property holder just so they can read
| and write the messages.
| _1tan wrote:
| I work with EDI (German energy industry) in a well regulated and
| accepted manner, no exceptions - and still our companies USP is
| that we provide a sane restful JSON API over EDI. It often feels
| like many developers simply don't feel the effort to learn the
| ins and outs is worth the effort.
___________________________________________________________________
(page generated 2022-09-12 23:00 UTC)