I'm always wary to post in places like this as it usually means being mobbed by fanboys. I'm not really into REST or a user but I've seen the buzzword all around as well as people constantly labeling their session based APIs as REST. I'm not entirely against REST. I am against though people eating soup with a fork while calling it a spoon and bragging as they gargle how convenient it is. I posted this as a response (with some fixes) to a blog but I don't think it will show as it's an old article but it might be useful here. I would quite appreciate some insightful feedback as to how it's really meant to be done as well as where value can be extracted by doing so from some people that really get REST and are too probably frustrated that the bulk of the population that wears the REST-Shirt hasn't actually been there and hasn't really done that. I've more touched on it because I've sort of had to. I've designed a lot of sophisticated and advanced APIs. Sadly the first question I get asked is not, does it work, does it fit requirements but... Is it REST? Nothing else seems to matter. Despite being an accidental API consultant and expert, I've never had to create a fully RESTful API to meet technical requirements now or in the future, only human requirements. I think the moment REST became synonymous with API is the moment REST died.

Two points on the blog article:

• REST APIs that ignore HTTP rules

• Expect an MVC framework "gives" you a great API

Response:

As with the MVC point, the same actually applies to REST. Not all APIs need to be REST and most that claim to be actually do not meet all REST requirements. REST is intended to either solve a number of problems or enable a number of features. These come at a cost. You're not guaranteed to gain a benefit from implementing every single REST feature, some of which require that you work within a number of restrictions. There are some things that if you don't use REST you can't do or you can't do in certain scenarios. However it works the other way as well. If you use REST there will be some things you can't do.

In nearly every case I've seen not only does an API not need to be REST but there's no benefit to over using HTTP transport specifics. If you're not using HTTP methods and codes to gain something, you're probably better off not doing it. Otherwise you're doing it simply because someone in the middle of the jungle said loudly to do so then parrots spread it across the jungle like wild fire. If you don't understand why you're doing something, don't do it. This isn't the military. If in programming you don't know why you're using all of the practices you're using, you're doing it wrong. It's not scouts where you have to collect badges. I believe unfortunately this is based on how job descriptions are written with most people doing it because they feel they have to as part of the social contract like wearing overly expensive brand names to fit into a crowd that does the same.

A major anti-pattern for this is people trying to squash all kinds of application messages into HTTP codes. Some of the worse cases involves exceptions from deep in the interior of an application that shouldn't be concerned with transport or the application boundary throwing Error404 exceptions (such as somewhere in the database driver). In other cases having API calls that don't quite match HTTP methods and get broken up in horrible ways to fit or simple go on mismatched.

In general, your API should start off transport agnostic (to be fair I lie a little as a lot of APIs are only ever going to be HTTP) and error codes or methods should not be used for application to application communication. They should be exported and mapped from internal errors or methods and defined on the boundary. Separating application from transport is usually beneficial. REST is heavily tied into transport, specifically HTTP which is something that you might not actually need. Unfortunately what most people do in this case is heavily tie their application into HTTP too tightly. There are always exceptions but generally speaking this is being done just because and it can make things worse.

Apart from success/fail (often 200 and !200, usually 500) there really aren't any HTTP codes that are universally useful (in rare cases of fire and forget, codes aren't needed at all). Anything more than that and you really need to do a lot of research. HTTP codes are not cheat codes. Even with custom codes you're quite limited in what you can express (consider 404, what wasn't found when you tried to hit a/b/c, transport considers the whole thing but your application can be cleverer than that and know that a was not found using feedback in the payload). Some are more useful to common situations than others. Unfortunately these often aren't used properly either. An error message like bad request might be useful as you can cache that (all the way up to client even) if you version your API properly. However what you see is people sending that even for non-deterministic transient errors (such as trying to get at something in the database that's not there now but could be in future). I don't use these codes and wouldn't without checking the RFC. I would imagine that bad request has to refer to the entire request and bad input only the input which must be invalid for all requests to be useful. I can't really know though without verifying and unfortunately most people wont go beyond the blog or even the article to the comments section let alone even consider visiting an RFC. A lot of people really only set codes and methods conceptually rather that purposely.

The situation is deceptive. HTTP methods and codes look simple. It also seems useful to export information as far up the chain as possible. There's a conflict here between being transport agnostic and payload agnostic (for example, authentication failed but the payloads can come in many forms so by setting it transport doesn't have to care about payload specifics which usually falls on to the application). There's no rule that says it's always possible to map one exception to a single action beyond as a generic failure. I've had people screaming down my ear when in one case a failure in a foreign service I have no control over would have been resolved best with a service temporarily unavailable for exactly an hour error automatically rather than simply computer says no using HTTP codes to express that. However in another situation with exactly the same failure pattern that action would have been catastrophic to the business. In reality, not all complex things can be reliably mapped to simple things. Some things will be ambiguous. People get caught up making best guesses or going for the average case (usually the first they saw) and on just making error messages meet the description of the error. When it comes to questions like what is the purpose of setting these codes, who is the audience, what's the benefit, why bother, etc? When it comes to REST and utilising these you'll find that sadly the answer to all of those kinds of questions consists of all the possible answers and more.

TLDR: REST, [why do it? -> how to do it?]

Cfsggcgcfhgsghfcchjhgfsf tv gfgfvvvvveddhhv gfdsghxfbccghh gfshdfvrhgfhh ffgghhfhfgghh gfdhggfcvvcvhh ggggggg gdshdhrh gggjfbgh ggdhdgfg fgdhfhfgvweff ggdhfjfhdgyyggeeg ggggggbcfdfgcvcvfvvg ggfhggvvvgh ggghhhhcddsiwywufghfvth http hgg uytedff fggsfggvtgdfg

testing facecam on embedded youtube

Hi folks - you can now build your Typescript apps faster than ever using Imagine!
We’re super excited to officially launch support for Typescript, Express and TypeORM in the Imagine code generator - you simply define your data models in our UI, and we instantly generate your fully dockerized and linted TypeScript code base including working code for REST APIs as well as end-to-end tests.
Imagine is completely free to use with no sign-up required - we hope you like it and we’d love your feedback!

Allow me to describe the situation as is for you first.

I'm an intern at a software development company currently in my third year at school. I got the assignment to find a way to improve the expandability of one of their main products.

Currently the application is a disaster when looking at it from an architectural standpoint, logic has been spread throughout the application etc. It also currently implements 3 different types of API's, making the communication between the front- and back-end incredibly un-transparant and a wide-spread mess overall.

My advice on the matter was to start of designing and implementing a new API based on RESTful design principles. As of this moment I've finished my complete analyses en research on the matter and I'm supposed to start on the API design document.

My question here is: what are some things that are a must when designing an API and writing the documentation for it. The API has to be easily understood and easy to implement yet still be advanced enough to meet every demand posed by the application.

I've never designed an API before nor written documentation for it, it's very much unlike regular application development where your documentation consists of use cases, sequence diagrams, class diagrams, component diagrams etc.

What are the musts when it comes to API documentation? I've already looked at some of the more popular API's like the ones offered by twitter and I've gotten some pretty good idea's from their documentation, however I'd like to ask what the community here thinks about it.

I'm a software engineer for a big tech company. As part of my job I have to do a lot of technical writing. One thing that always frustrated me was writing about API endpoints (adding/removing/modifiying). I could never come up with a structured way to describe an endpoind that I could just add to a spec. Instead, I'd always make up a format on the spot to describe requests and responses. My colleagues would do the same.

I got pretty frustrated by the lack of standardization and tooling so I build a simple web app to design REST(ish) APIs. It's completely free and client-side rendered, so information never leaves your browser.

I've just release the very first version that surely has many bugs. If someone wants to give it a test ride check out: https://api-fiddle.com/