api-design

Overview I am currently in the process of creating an API for an image sharing app that will run on the web and sometime in the future, on mobile. I understood the logical parts of API building, but I'm still struggling to meet my own requirements for the authentication part. So, my API must be accessible to the world: those with guest access (non logged in people can upload, for example), and also to registered users. So when a registered user uploads, I obviously want the user information to be sent along with the request and to attach that user information to the uploaded image via foreign

I was recently watching a webcast about how to create a fluent DSL and I have to admit, I don't understand the reasons why one would use such an approach (at least for the given example). The webcast presented an image resizing class, that allows you to specify an input-image, resize it and save it to an output-file using the following syntax (using C#): Sizer sizer = new Sizer(); sizer.FromImage(inputImage) .ToLocation(outputImage) .ReduceByPercent(50) .OutputImageFormat(ImageFormat.Jpeg) .Save(); I don't understand how this is better than a "conventional" method that takes some parameters:

String in Java is immutable. The following snippet is, broadly speaking, "wrong". String s = "hello world!"; s.toUpperCase(); // "wrong"!! System.out.println(s); // still "hello world!"!!! Despite this being "wrong", the code compiles and runs, perhaps to the confusion of many beginners, who must either be told what the mistake is, or to find out for themselves by consulting the documentation. Reading the documentation is an essential part of understanding an API, but I'm wondering if this can be supplemented by additional compile-time checks. In particular, I'm wondering if perhaps Java's

I despise working with overengineered APIs that don't make simple things simple. Nonetheless, I'm working on designing an API for an open-source library and I'm starting to feel that I'm falling into the overengineering trap. I really can't tell for sure because, of course, I wrote the darn thing, so how it works is more obvious to me than anyone else. What are some warning signs from a developer's perspective that your API might be overengineered? "What are some warning signs from a developer's perspective that your API might be overengineered?" No use cases. If you can't run through simple

I'm going to build an API for a web app and I'm interested in what people can suggest as good practices. I'm already planning to make it versioned (version 1 can only control certain aspects of the system, version 2 could control more, but this may need a change in the way authentication is performed that would be incompatible with version 1), and the authentication will be distinct from the standard username/password people use to log in (if someone does use a malicious tool it won't open them up to full impersonation, just whatever the api allows). Does anyone have further ideas, or examples

I need to make a REST API for a file upload service that allows a user to: Open a session Upload a bunch of files Close the session And then later, come back and do things with the files they uploaded in a previous session. To facilitate dealing with data about each file and dealing with the content of the file itself, this is the URI scheme I am thinking of using: /sessions/ /sessions/3 /sessions/3/files /sessions/3/files/5 /sessions/3/file/5/content /sessions/3/file/5/metadata This will allow the file metadata to be dealt with seperately from the file content. In this case, only a GET is

What are some guidelines and best practices that I can adhere to while designing an API? At the bare minimum, I know that an API should be easy to use and flexible. Unfortunately those terms can be rather subjective, so I was looking for some concrete guidelines relating to good API design. Gishu I found the following to be worth a watch Joshua Bloch - How To Design A Good API and Why it Matters The examples are in Java though but still you can draw parallels. Since you didn't mention a specific technology ; I assume you don't want niche solutions. Jeff Meatball Yang As someone who has to