api-design | 易学教程

Is it useful to always return a promise

阅读更多关于 Is it useful to always return a promise

问题 I'm using bluebird to design some nodejs api wrapper around an http service. Many of the functions in this wrapper are asynchronous and so it makes a lot of sense to return promises from these implementation. My colleague has been working on the project for a few days now and interesting pattern is emerging, he is also returning promises from synchronously implemented functions. Example: function parseArray(someArray){ var result; // synchronous implementation return Promise.resolve(result);

REST api versioning (only version the representation, not the resource itself)

阅读更多关于 REST api versioning (only version the representation, not the resource itself)

问题 I had a look at Best practices for API versioning?, but am not quite convinced of the answer, so I am question the versioning part again with a more specific example. I am having two URIs (one with versioning as part of the URI and one without): http://xxxx/v1/user/123 -> favored solution in discussed thread http://xxxx/user/123 I am having my doubts whether the first link expresses the idea of REST. I find http://xxxx/v1/user/123 confusing as it suggests that there will be a higher api

When do I use path params vs. query params in a RESTful API?

阅读更多关于 When do I use path params vs. query params in a RESTful API?

问题 I want to make my RESTful API very predictable. What is the best practice for deciding when to make a segmentation of data using the URI rather than by using query params. It makes sense to me that system parameters that support pagination, sorting, and grouping be after the '?' But what about fields like 'status' and 'region' or other attributes that segment your collection? If those are to be query params as well, what is the rule of thumb on knowing when to use path params? 回答1: Best

Call a Server-side Method on a Resource in a RESTful Way

阅读更多关于 Call a Server-side Method on a Resource in a RESTful Way

问题 Keep in mind I have a rudimentary understanding of REST. Let's say I have this URL: http://api.animals.com/v1/dogs/1/ And now, I want to make the server make the dog bark. Only the server knows how to do this. Let's say I want to have it run on a CRON job that makes the dog bark every 10 minutes for the rest of eternity. What does that call look like? I kind of want to do this: URL request: ACTION http://api.animals.com/v1/dogs/1/ In the request body: {"action":"bark"} Before you get mad at

What is the proper REST response code for a valid request but an empty data?

阅读更多关于 What is the proper REST response code for a valid request but an empty data?

For example you run a GET request for users/9 but there is no user with id #9. Which is the best response code? 200 OK 202 Accepted 204 No Content 400 Bad Request 404 Not Found Crisfole TL;DR: Use 404 See This Blog . It explains it very well. Summary of the blog's comments on 204 : 204 No Content is not terribly useful as a response code for a browser (although according to the HTTP spec browsers do need to understand it as a 'don't change the view' response code). 204 No Content is however, very useful for ajax web services which may want to indicate success without having to return something

Why Java does not allow overriding equals(Object) in an Enum?

阅读更多关于 Why Java does not allow overriding equals(Object) in an Enum?

问题 I've noticed that the following snippet... @Override public boolean equals(Object otherObject) { ... } ...is not allowed for an Enum, since the method equals(Object x) is defined as final in Enum. Why is this so? I cannot think of any use case which would require overriding equals(Object) for Enum. I'm just curious to know the reasoning behind this behavior. 回答1: Anything but return this == other would be counter intuitive and violate the principle of least astonishment. Two enum constants

Why does int num = Integer.getInteger(“123”) throw NullPointerException?

阅读更多关于 Why does int num = Integer.getInteger(“123”) throw NullPointerException?

The following code throws NullPointerException : int num = Integer.getInteger("123"); Is my compiler invoking getInteger on null since it's static? That doesn't make any sense! What's happening? polygenelubricants The Big Picture There are two issues at play here: Integer getInteger(String) doesn't do what you think it does It returns null in this case the assignment from Integer to int causes auto-unboxing Since the Integer is null , NullPointerException is thrown To parse (String) "123" to (int) 123 , you can use e.g. int Integer.parseInt(String) . References Java Language Guide/Autoboxing

Why does String.valueOf(null) throw a NullPointerException?

阅读更多关于 Why does String.valueOf(null) throw a NullPointerException?

according to the documentation, the method String.valueOf(Object obj) returns: if the argument is null , then a string equal to "null" ; otherwise, the value of obj.toString() is returned. But how come when I try do this: System.out.println("String.valueOf(null) = " + String.valueOf(null)); it throws NPE instead? (try it yourself if you don't believe!) Exception in thread "main" java.lang.NullPointerException at java.lang.String.(Unknown Source) at java.lang.String.valueOf(Unknown Source) How come this is happening? Is the documentation lying to me? Is this a major bug in Java?

Why are Java Streams once-off?

阅读更多关于 Why are Java Streams once-off?

Unlike C#'s IEnumerable , where an execution pipeline can be executed as many times as we want, in Java a stream can be 'iterated' only once. Any call to a terminal operation closes the stream, rendering it unusable. This 'feature' takes away a lot of power. I imagine the reason for this is not technical. What were the design considerations behind this strange restriction? Edit: in order to demonstrate what I am talking about, consider the following implementation of Quick-Sort in C#: IEnumerable<int> QuickSort(IEnumerable<int> ints) { if (!ints.Any()) { return Enumerable.Empty<int>(); } int

Should an async API ever throw synchronously?

阅读更多关于 Should an async API ever throw synchronously?

I'm writing a JavaScript function that makes an HTTP request and returns a promise for the result (but this question applies equally for a callback-based implementation). If I know immediately that the arguments supplied for the function are invalid, should the function throw synchronously, or should it return a rejected promise (or, if you prefer, invoke callback with an Error instance)? How important is it that an async function should always behave in an async manner, particularly for error conditions? Is it OK to throw if you know that the program is not in a suitable state for the async