3 ms·
This article is a bit misguided, and contains multiple fundamental missunderstandings, first no history: You need to know the mess that was SOAP before you go
by bullen 6y ago
This article is a bit misguided, and contains multiple fundamental missunderstandings, first no history:
You need to know the mess that was SOAP before you go into REST, like you need to know about XML before you criticize JSON.
JSON is not a good place to put anything but data, to specify an API with a meta language has been disproven by SOAP already.
My approach to end all API fragmentation is to simply use JSON over HTTP with minimalism!
I do not conform to REST, but instead exclusively use GET and POST and return 200 everywhere and handle everything manually from there.
I also make HTML forms to all API entrypoints so you can test and learn how the API works by browsing and viewing source.
http://root.rupy.se http://root.rupy.se
- ncrmro 6y agoI’m pretty sure you just described GraphQL. All errors are 200 unless they are HTTP errors. The backend error is under the errors key in the json. All post requests.
- mort96 6y agoHe just described, well, most web APIs. Client POSTs to some endpoint, the server responds with 200 and a payload. Application-level errors are part of the payload. Trying to merge the application API and HTTP concepts (like HTTP methods and HTTP response codes) seems to mostly just be a REST thing. Most other APIs treat HTTP as a transport layer in my experience.
- psturgeon 6y agoIgnoring all the layers of HTTP to use it as a dumb tunnel is a really effective way of forcing everyone to reinvent a lot of wheels at every phase of the interaction. A lot of people do it, its usually a brittle and expensive waste of time.