Tag Info

Hot answers tagged

30

Call it an HTTP API. It conforms to HTTP standards, and doesn't have anything else layered on top (e.g. SOAP). The HTTP standards define resources, verbs, headers, content negotiation, etc. REST (REpresentational State Transfer) is an architecture with requirements that happen to be amenable to existing HTTP standards, but HTTP works on all its own. ...


17

Richardson Maturity Models goes like this POST everywhere. A single endpoint. (SOAP) POST everywhere. Multiple endpoints. (resources) HTTP VERBS. Multiple endpoints. Like 2 and returns links to resources. (RESTful) So according to the model I would call it a webservice conforming to richardson level 2 or something along those lines. ...


5

There are two ways you can view your diagnostic information: part of an existing resource, or a separate resource. How you view it depends on your application requirements. If the information is part of an existing resource, then you have the most "RESTful" representation possible. Note that REST does not strictly place requirements on the structure of your ...


4

Hypermedia never really got popular with REST-like APIs - to the point that when an API actually implements hypermedia navigation, the term RESTful simply isn't enough to distinguish it from any other "RESTful" web APIs. REST has become an catch-all term or any resource-based web APIs and new names like Hypermedia API have been coined to focus on ...


3

If you allow a client to access the database directly - which they would do, even with a database abstraction layer, then: You get a coupling between their code and yours - particularly, there is a very strong coupling between your database structure and their code; Your client may do some pretty undesirable stuff on your database - whether it be updating ...


3

No. REST doesn't care about how your organize your resources, only that individual resources are identified by URLs and that resources are discoverable from other resources. If api/competitions/{id}/teams/players makes sense for your application then use it, as long as users can find a link to it. Roy Fielding's dissertation on Representational State ...


3

According to the documentation, anonymous information about the user's system is sent with an update request. I'd say that technically your colleagues are correct. This info doesn't appear to be used to affect the response to the request, so it doesn't really belong there. A better way to send that info would probably be to POST to a separate resource, ...


3

RFC 7231, Section 4.3.1: A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. So in short, sending a payload is indeed incorrect. As far as REST goes, use POST if you're creating an item, and PATCH for partial updates or PUT for full ...


2

It is a CRUD interface (Create, Read, Update, Delete) over HTTP. I can't think of any authorities to back it up this assertion, so I hope you get more and better answers.


2

As Frank said, you appear to have figured out a lot of this on your own already, so I only have one piece of advice regarding the main question. Do the refactoring gradually, incrementally, alongside whatever changes you make to add business value. Don't try to break the 5000 LOC monster into five 1000 LOC critters all in one go. As long as you keep in mind ...


1

If I understand correctly what a DBAL is, then the answer is that a REST interface allows you to use any language for its clients, while a DBAL is a library that allows you to use a single language for its clients. This, in turn, can be an advantage for a company where there are many development teams and not all of them are proficient in the same language. ...


1

You are thinking that REST is for database queries and it is not. REST represents the state of something at the moment. Using REST changes or retrieves a representation but that is all. If that state becomes available by database, it doesn't matter and no one cares because HOW that representation comes to be is not part of REST and neither are database ...


1

You can call it a Web API. It's a very broad term but it can avoid nitpicking about meaning of other API type definitions. The term is less technical and precise compared to alternatives like HTTP API, but that might be an advantage when talking to non-technical people. This term is also used by Leonard Richardson (who defined the Richardson Maturity Model ...


1

You can call it whatever you like, people tend to (almost religiously) latch onto any part of the REST 'spec' that you're not following and use that as a point of protest which is highly detrimental to the development. But that said, the simple fact is that there are (nearly) zero services exist that implement true REST for their API serves. In our team we ...


1

It's all about discovery: the ability of your API to be understandable and usable by the next developer encountering it. If the WebSocket methods are easily discoverable, and it is clear that they should be used in conjunction with the ordinary REST methods, then your design is probably sound. In practice, for this discovery to occur, I think your ...


1

A resource is a resource. The resource doesn't change simply because the permissions change. What you can do with the resource or what you can know about the resource might change, but the mapping of the resource doesn't change. If it does it becomes a different resource type. So in your description, it's conceivable that various properties would exist at ...


1

I can see some sensible answers to this question already, but I thought I would expand and offer my opinion. You've described a system that appears to couple logic into large classes, and be tightly coupled across many different functions. The first way to try and refactor this is to first ensure you understand what a 'good' architecture/codebase would ...


1

Of course, I never saw your actual code, but from what you've said, I would propose something close to the following architecture. I'm sorry for pseudo-code, I just wanted it to be fast & clear ;) UI layer: dataService = new DataService(); dataService->makeDataRequest(requestName, requestParams[], cachedDataArrivedCallback, ...



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