Open Wade-USGS opened 2 years ago
Wade-USGS
commented
2 years ago Just a note this could be totally wrong and a better standard definition exists that meshes with what's included... I'm wondering if we'd be better off just calling everything an API, though? Why try to differentiate? Does it help the user find what they need easier? If not, just call things USGS Water API with location, discrete WQ, TS, etc... endpoints within it.
flagbrad
commented
2 years ago Thanks @Wade-USGS. I'll double check this a little more and if I got the sense of these reversed I'll definitely flip them around.
The reason I think some distinction helps here is mostly about the URL input arguments. If they're just home-grown ones (like the usual IV service), it's not as interoperable as the ones that have a formal open standard for the URL input argument (like SensorThings)
flagbrad
commented
2 years ago I have revised the article per @Wade-USGS's suggestion, in a forthcoming pull request. Good catch! I think it's easier to read now. Basically I call everything an API or a Web API... except the really old (late 90s) Web URLs that output RDB files. For those I still call them endpoints, because the designers didn't develop them to be well-documented formal APIs (even though people have reverse engineered them and used them that way)
May not matter in this context but definition/delineation of web service/api doesn't seem to mesh well with most I've seen out there. Example here: Web service is a collection of open source protocols and standards used for exchanging data between systems or applications whereas API is a software interface that allows two applications to interact with each other without any user involvement. Web service is used for REST, SOAP and XML-RPC for communication while API is used for any style of communication. Web service supports only HTTP protocol whereas API supports HTTP/HTTPS protocol. Web service supports XML while API supports XML and JSON. All Web services are APIs but all APIs are not web services.