Currently I'm working on a CMS containing on a RESTful webservice. For the regular REST actions, I use the default HTTP methods GET, PUT, POST and DELETE. However, I'm thinking of adding a custom method MAINTENANCE, which I can use for maintenance purposes, like integrity checks, re-indexing, etc. These kind of maintenance can only be invoked by administrators of the CMS.
My webservice supports overriding the HTTP method by defining the url parameter _method. This way I can 'post' a form, setting the _method to PUT. I can also use this same parameter to set the method to MAINTENANCE. Technically it is fairly easy to implement a custom HTTP method.
My questions is more ethical about proper design. On one hand, custom HTTP methods are allowed and technically not difficult to implement. On the other hand, some people advice not to use custom HTTP methods.
Should I use custom HTTP methods for maintenance tasks? Or are there other best practices?
Integrity checks and re-indexing are not resource actions that you want to expose to a user. These can be achieved via a different servlet that's non_REST.
Adding more methods to HTTP is not a normal practice. You can look some to the REST interfaces that are public.
Related
I'm designing a REST API (implemented with ASP.NET Web API, not ASP.NET core, because we can't upgrade it right now).
I'm looking for the best solution to partially update an entity.
For example, the "Person" entity has 100 properties, and a third party system only has to update the "PersonValidityDate".
What is the best and simplest solution to do it ?
I read some article about the PATCH verb, with JSON patch or JSON merge patch, but it seems a bit complicated and not supported by everyone... Is it ?
I'm looking for a very simple solution to do it, that any integrator can understand and use...
What do you suggest ? Is PATCH often used?
If I use POST/PUT and only give the properties to update and ignore the other properties, when the body is deserialized, nullable properties will be null. How can I distinguish the properties set to NULL explicitely and not provided properties ?
According to RFC 5789
Several applications extending the Hypertext
Transfer Protocol (HTTP) require a feature to do partial resource
modification. The existing HTTP PUT method only allows a complete
replacement of a document. This proposal adds a new HTTP method,
PATCH, to modify an existing HTTP resource.
So you should use a PATCH request for partial update of the object and PUT for complete object replacement.
And you should not use the complete model in patch request with empty/null fields instead use the new model for PATCH request.
You can check more example here
I'm currently trying to figure out which options does retrofit offer to add an interceptor only to specific calls.
Background & use cases
I'm currently using retrofit 1.9
The use case is pretty simple. Imagine a user who needs to login and get a session token. There is a call.
/**
* Call the backend and request a session token
*/
#POST("auht_endpoint")
Observable<Session> login(...);
All other calls will require a token from the above session in the form of a request header. In other words, all subsequent calls will have a header which provides the session token to the backend.
My question
Is there a simple way of adding this header only to specific calls through interceptors?
What I've tried so far
Obviously the easiest approach was to add the #Header annotation to the specific calls and providing the token as a parameter
I guess one can inspect the url in the request inside the interceptor. Not very flexible.
Create different rest adapters with different interceptors. I heard you should avoid creating several instances of the rest adapter for performance reasons.
Additional info
I'm not committed to interceptors, I would use other solutions
I've said I'm using retrofit 1.9, but I'd be also interested in a way to do it with retrofit 2.x
Please note this is not an answer, comment box was too small.
I've recently had this problem and I came up to the same possible solutions as you.
First of all I put aside double adapters - thats a last resort.
#Header field seems ok, bacause you explicitly define that this specific request needs authorization. However it's kinda boring to use.
Url inspection in interceptor looks "ugly", but I've decided to go with that. I mean if all requests from a one specific endpoint need that authorization header then what's the problem?
I had two other ideas:
Somehow dynamically replace/modify okHttpClient which is used with Retrofit. After some tests I figured that it's not possible.
Maybe create some custom annotation #AddAuthorizationHeader to the call definition, which will do everything for you, but I guess it wouldn't be possible either.
And in this matter Retrofit 2.x doesn't bring anything new.
Please let me know if the premise of my question even makes sense...
I have a WSDL file from an existing (locally served) web service. I would like to "wrap" that web service with a Web API so I can easily make RESTful AJAX calls to it. If I add the WSDL as a Service Reference, I can write controllers and make calls.
I guess my questions are two things:
Is there some easy way to expose all the WSDL actions without manually writing controllers for each one?
Is this even a good idea in concept? Is there a better way to create a nice client AJAX relationship that I'm not thinking of?
Yes, it is a good idea in concept. Abstracting the ASMX for the clients and providing an easy REST based endpoint is good.
I'm assuming the ASMX is a separate component in itself and doesn't share any Middle-tier code with your Web API project.
It is okay to abstract out the ASMX.
As for an easy way to expose all the WSDL actions as controller actions, how many Web methods are we talking about?
Typically we only have a single ASMX web service with a few web methods. (5-15)
If you have just a few, creating a single controller with 10-15 actions should not be that painful.
On the other hand, if you have unmanageable number of web methods, you might want to think of Text Template files (.tt) to generate controllers out of 'Reference.cs' files. (proxy file) i don't think there are auto-tools to convert asmx to a web api controller.
i have found it easier to hand-write the web api controller due to the nitty-gritty of the request/response types, return types, [FromBody] [FromUri] attributes, HttpPost, HttpGet attributes, and of course the action definition itself.
The text template logic could get error-prone trying to figure out HttpPost actions vs. HttpGet etc.
Also, a good controller will end up having injected dependencies for Data Access, Caching etc. and you would want direct control on the class, rather than being created by an automatic tool.
I have many webmethods in one asmx. I need to perform licence checking before some of this webmethods invoked. I can insert following code to each web method that needs checking:
if (!AllRight())
{
// badRequest
return;
}
Or I can insert complex filter to HttpModule to detect webmethod by URL.
I need something like attribute for webmethod and place where I can handle it.
Is there pretty good solution?
IMO, both of these options are good. Using HttpModule is a good approach - detecting web service call by parsing url is really simple - in short, you are looking for particular asmx (and handling WSDL request). If you want to do selective license check then do simple method name sniffing in URL (as opposed to decorating methods with attribute).
Apart from above options, you have couple of alternatives
Uses some Aspect Oriented Programming frameworks (for example, PostSharp) to inject license checking code by using attribute to decorate the method.
Do it at handler level. Essentially, implement a IHttpHandlerFactory and use it for your asmx end points. The implementation will wrap WebServiceHandlerFactory (or ScriptHandlerFactory in ajax cases) and will return a handler that wraps over the handler object provided by underlying handler. But frankly, this is a brittle solution and essentially same as HttpModule but more complicated.
Instead of using the web services infrastructure provided by .net, I was wondering what your take on rolling my own asp.net page that you can post data to (I guess all the cool kids are calling this REST,) and retrieving a JSON response from. Is there additional overhead in using an aspx page for this purpose that i'm not aware of?
Yes and no. You can use ASP.NET, even without MVC, to handle this rather effectively. But you probably don't want to use pages. Rather, you should implement IHttpHandlers for your rest actions.
As for handling the JSON angle, check out JSON.NET if you don't want to use the baked-in WCF/Scripting stuff.
Even if you'd use existent helper classes, you'd have to implement your own message parsing (including error handling etc.) and thus lose transport transparency (would require more effort to switch to other protocols/formats) unless you implement a communication infrastructure similar to WCF's. And then you might need additional features such as security..... just use WCF if you can ;)