Tag Info

Hot answers tagged

209

Yes you should. It not only makes your back end re-usable but allows for more security and better design. If you write your backend as part of a single system, you're making a monolithic design that's never easy to extend, replace or enhance. One area where this is popular at the moment is in Microservices. Where the backend is split into many little (or ...


89

Your example is broken. You shouldn't have json objects with duplicate keys. What you are looking for is an array with movie objects, like this: [ {"name": "movie1"}, {"name": "movie2"} ] This approach also answers your question. You should return an empty array when the query does not match: [] On the other hand, if you try to get a ...


77

Imagine you have to use someone else's code designed as about below: class Messy { String concat(String param, String str) { /* ... */ } boolean contains(String param, String s) { /* ... */ } boolean isEmpty(String param) { /* ... */ } boolean matches(String param, String regex) { /* ... */ } boolean ...


65

I'm not going to address the design problem - just the question of whether to do things "correctly" in a non-public API. it's just for me, so it's kind of like I'm protecting my own code from myself That's exactly the point. Maybe there's coders out there who remember the nuances of every class and method they ever wrote and never mistakenly call into ...


58

From a guy who's used both SOAP and REST extensively... BOSS says SOAP is... richer and more expressive Anytime someone says a product is "rich" I want to become violently ill. I can't think of a more cliche comment to make about a technology or platform. Basically you're saying "I think this product is great, but I don't have any actual facts to ...


53

I know microservices are all the rage right now, but they aren't always worth it. Yes, loosely coupled code is the goal. But it shouldn't come at the expense of a more painful development cycle. A good middle ground would be to create a separate data project in your solution. The data project would be a .NET class library. Your ASP.NET MVC project would ...


53

You cannot possibly avoid building an API. Even if you build "just a Website", it will still need to get its data from your backend somehow. However you decide to do this, that is your de facto API. Knowing this, the real question isn't whether to build an API, but how to build it. You can do it on-the-fly as an ad hoc thing -and indeed, many Websites are ...


42

In your latter scheme, you keep verbs in the URLs of your resources. This should be avoided as the HTTP verbs should be used for that purpose. Embrace the underlying protocol instead of ignoring, duplicating or overriding it. Just look at DELETE /item/delete/:id, you place the same information twice in the same request. This is superfluous and should be ...


35

Usually I would return number of records in result as metadata. I am not sure if that is normal REST practice, but it is not much extra data, and it is very precise. Usually there is pagination for lots of services, it is impractical to return huge resultset at once. Personally I am annoyed when there is pagination for small result sets.. If it is empty, ...


32

It is generally true for any public API, yes. Once you expose an API to the public and people start to build applications that depend on that API, it becomes extremely difficult to change the API because doing so will break all those applications. That tends to be both a difficult technical problem and a difficult political problem. Of course, it is ...


29

Crockford has given an extensive presentation titled "An Inconvenient API: The Theory of the Dom" where he more or less explains his opinions on the DOM. It's longish (1h 18m), but as most Crockford's presentations it's quite enjoyable and educative. Cross browsers inconsistencies seems to be his main concern, and I agree it's the single most annoying ...


29

How about doing both? Have a "low level" (so to speak) API that exposes functions of the system and have another "layer" that exposes services that a client might want to do. This layer would use the necessary low level API's required but those are still exposed if the client wants them. UPDATE: To also include some of the great points and comments made ...


28

Your desire not to split it out into three method calls is completely understandable, but you do have other options besides boolean parameters. You could use enums: falconPeer.SetVisibility(JoinRequestOptions.Accept, "aerw3", DiscoveryRequestOptions.Reply); Or even a flags enum (if your language supports it): ...


28

No you shouldn't. If you don't have immediate plans to create alternative frontends (like mobile or desktop apps or separate web application) which access the same backend, then you shouldn't introduce a web service layer. YAGNI. Loose coupling is always desirable (along with high cohesion), but it is a design principle and does not mean you have to ...


27

The returning of null makes sense to me since manipulating a null string should result in a null string, not an error Well, that is your opinion. Others may argument that String operations on a null object, which does not contain a String, make no sense and hence should throw an Exception Why "Java designers" did or did not something is difficult to ...


27

My company has one application built like this. Initially we were commissioned to build a back end with API for a front end that another developer was creating. When the other developer couldn't develop that front end we were commissioned to build the front end too. While there are definitely benefits to this approach there is a huge disadvantage: cost. The ...


25

Don't provide multiple ways to do the same thing - that will just confuse the API users. Having several names for the same things means you don't have a good name for it.


25

The "simple is better" mantra has become too much dogmatic. Simple is not always better if it complicates other things. Assembly is simple - each command is much simpler than higher-level languages commands - and yet Assembly programs are more complex than higher-level languages that do the same thing. In your case, the uniform handle type enh makes the ...


21

Null may be a valid value for an element of a list. Say your list contains elements which represent some optional data about a list of users and is stored in the same order as the users. If the extra data is populated then your list will contain the additional data otherwise the slot corresponding to a user will be null. (I'm sure there are better ...


21

This design decision appears mostly driven by naming. Name ArrayList suggests to reader a functionality similar to arrays - and it is natural for Java Collections Framework designers to expect that vast majority of API users will rely on it functioning similar to arrays. This in particular, involves treatment of null elements. API user knowing that below ...


21

Your question, as I understand it, seems to be based on an incorrect premise. Let me see if I can reconstruct the reasoning: The linked-to article describes how automatically-generated sequences exhibit a "lazy" behaviour, and shows how this can lead to a counter-intuitive result. Therefore I can detect whether a given instance of IEnumerable is going to ...


21

I usually follow some simple rules: Try to always program by contract. If a method is publicly available or receives input from the outside world, enforce some defensive measures (e.g. IllegalArgumentException). For everything else that is only accessible internally, use assertions (e.g. assert input != null). If a client is really into it, they will ...


18

It depends on how many fields you're talking about, and how they are used. Concrete is preferable for highly structured queries with only a few fields, but if the querying tends to be very free form, then the concrete approach quickly becomes unwieldy with more than three or four fields. On the other hand, it's very difficult to keep a generic API pure. ...


17

You have to be careful to avoid adding new vocabulary just for the sake of your API. My favorite APIs explain things to me in vocabulary I already understand. Along those lines: Don't add too many abstractions on top of what you're building on. Keep it simple. I already have to think about about half-a-dozen layers of abstraction. Dont make me think about ...


17

The whole of the Internet is built on conventions. We call them RFCs. While nobody will come and arrest you if you violate an RFC, you do run the risk that your service will not interoperate with the rest of the world. And if that happens, you run the risk of your startup not getting any customers, your business getting bad press, your stockholders ...


17

It depends on the type of application and the type of market you are in. There are trade-offs and benefits to going this way. It is not a clear-cut answer that one way is better than the other. I'll talk from personal experience. I was the one who decided to take the codebase that I work on in this direction back in 2007. That codebase is somewhere in the ...


16

a last() method is just as easy as list.get(list.size()-1), just like there is no first() method or fifth() method. It isn't that hard to synthesize and is a specialization. You can also reverse() the list and list.get(0) which will give the last item. Things that are easy to do, usually don't get their own specialized methods. import java.util.ArrayList; ...


16

You should not forget that GET requests have some superior advantages over other solutions: 1) GET requests can be copied from the URL bar, they are digested by search engines, they are "friendly". Where "friendly" means that normally a GET request should not modify anything inside your application (idempotent). This is the standard case for a search. 2) ...


16

An API should be as consistent as possible. Making the same call to the API should always do the same thing. Responding differently based on the client version would be unexpected and confusing. It may lead to subtle errors, as someone who upgrades a client would get different results and not know why. Of course, you can make functions that provide ...



Only top voted, non community-wiki answers of a minimum length are eligible